Controlling Access to Scripts

There are several approaches in protecting FoxWeb scripts, each having its own advantages and disadvantages:

The Auth Object

FoxWeb's Auth object is the easiest way to implement a powerful authentication system to protect your scripts. The Auth object utilizes an HTML form to exchange login information between the browser and the server, and identifies an authenticated user by storing information in Session variables.

The Auth object has lots of features, which make it a very powerful solution, such as an inactivity timeout, flexible login form design, and properties that indicate the time the user logged in and whether this is the first hit after a successful login. Users are typically authenticated against a table, containing user id/password information. For simple applications with just a few users, you can store authentication information in the AuthList property instead.

Storing user information in a table, offers a number of advantages over using the Web server's native security mechanism, such as easy management, and the ability to store additional user properties. The disadvantage of the Auth object is that it can not protect static files. One way to get around this is to use VFP's FILETOSTR function to read these files into a variable and then serve them directly from FoxWeb scripts. If the files are not of type HTML then you will need to specify the ContentType.

Security Warning: The Auth object utilizes an HTML form to collect the user id and password. This information normally travels as clear text over the Internet. To avoid having passwords intercepted in transit force the use of SSL/HTTPS.

HTTP-Basic Authentication

Another way to add security to your programs is to use HTTP_Basic authentication. This technique involves sending a "401 Unauthorized" HTTP header to the browser, which causes it to pop up a login dialog box. HTTP-Basic authentication does not require cookies: once the user is authenticated, the browser automatically remembers the password and sends it to the server with all subsequent requests. Scripts can retrieve the password by calling Request.ServerVariables("AUTH_USER"). If you choose this technique you will not have access to certain features that the Auth object provides, such as inactivity timeout, HTML login forms, the ability to log a user out, etc..

If you are using Microsoft IIS or Microsoft Personal Web Server (PWS) for Windows NT/2000, then the easiest way to implement this method is to enable Use Web Server's Directory Mappings in the FoxWeb Control Center. This will enable you to set user rights to individual script files, just like you would do for static files. In order to protect a script or a static file, simply use the Windows Explorer to remove rights for the IUSR_ComputerName and IWAM_ComputerName accounts. The server will return a "401 Unauthorized" header to the browser, which will cause it to pop up a login dialog. In order for this technique to work you will need to convert your file system to NTFS, enable HTTP Basic Authentication in your Web server's Directory Security configuration, and enable the "Check that File Exists" setting for the .fwx script mapping. An advantage of this method is that you can use the same system to protect static HTML files as well as FoxWeb programs. For more information on configuring your Web server and using its security features refer to your server's documentation.

If you are not using IIS or PWS for Windows NT/2000, or if you do not want to enable the Use Web Server's Directory Mappings setting, you can still use HTTP-Basic authentication, by including the following code at the top of protected programs:

<%
IF NOT INLIST(Request.ServerVariables("AUTH_USER"), "mike", "joe", "dan")
    Response.Status = "401 Unauthorized"
    Response.AddHeader('WWW-Authenticate', 'basic realm="FoxWeb"')
    Response.End
ENDIF
* The following code will only be executed after the user gets authenticated
%>

<head><title>Members Area</title></head>
<body><h1>Members Area</h1>
.
. (protected content)
.
</body>

Note that different Web servers react differently to this technique. IIS and PWS, authenticate the user before passing control to the script, so you are stuck with using the server's user database. Other servers simply pass the user name and password to the script, which has to do the authentication in code. If you need to authenticate the user in the script then you need to be using a Web server that passes the password to the script in the AUTH_PASSWORD server variable. O'Reilly WebSite only does so if the CGI program's name starts with an ampersand (&), in which case you may need to rename foxweb.exe. Consult your Web server's documentation and contact the software manufacturer's technical support team for information on how to implement HTTP-Basic authentication from CGI and/or ISAPI scripts with your particular server.

Security Warning: HTTP-Basic authentication sends passwords as clear text over the Internet. To avoid having passwords intercepted in transit force the use of SSL/HTTPS.

IP Security

FoxWeb programming can also be used to do ip or domain-based authentication. For this your program would have to check the value of the REMOTE_ADDR or REMOTE_HOST server variables. The following example restricts access the current script to browsers from the domain 128.29.33.*:

<%
IF NOT LIKE('128.29.33.*', Request.ServerVariables("REMOTE_ADDR"))
    Response.Write("You are not authorized to view this page")
    Response.End
ENDIF
%>

.
. (protected content)<br>
.

© Aegis Group