One of the challenges to developing an effective Web application is maintaining user information over the course of a visit, or session, as the user travels from page to page in an application. HTTP is a stateless protocol, meaning that your Web server treats each HTTP request as an independent request. The server has no knowledge of previous requests, even if they occurred only seconds prior to a current request. This means that even if you just requested thirty pages in a row from a particular Web server, if you were to request a thirty-first page the server still wouldn't know you from any other user.
This inability of a Web server to track previous requests makes it difficult to write applications, such as shopping carts, where it is important to track the items that a user has selected while visiting the various product pages.
Traditionally Web application programmers have used cookies as a means of associating requests from the same user and for storing information that should persist throughout the user session. FoxWeb supports cookies, but also provides another means of maintaining user information over the course of a visit -- the Session object.
The easiest and most effective technique for managing session information in FoxWeb scripts is the Session object. Using the FoxWeb Session object you can create applications that identify each visiting user and collect information that your application can then use to track user selections or preferences.
A new session is automatically created whenever the server receives a request that does not contain a valid SessionID cookie. Sessions automatically end if a user has not requested a FoxWeb script for a specified period of time, called the Session Timeout. The default value for the Session Timeout is 20 minutes. You can globally change this value using the FoxWeb Control Center. Alternatively, you can change the Session Timeout for a particular user session, by setting the Session.Timeout property.
You can deliberately end a session with the Abandon method of the Session object. For example, your pages can include a Logout link, which points to a script containing a call to the Session.Abandon method.
The first time a user requests a FoxWeb script on a given server, FoxWeb creates a SessionID, which is simply a randomly generated unique identifier. At the beginning of a new session, FoxWeb stores the Session ID in the user's Web browser as a cookie.
After storing the Session ID cookie in the user's browser, FoxWeb reuses the same cookie to track the session, even if the user requests another FoxWeb script. If a session expires or is explicitly destroyed with the Abandon method and then the user proceeds to call another script, FoxWeb starts a new session using the old Session ID. The only time users receive a new SessionID cookie is after they restart their Web browser.
FoxWeb will not send session cookies or maintain session variables on the server if you disable sessions in the FoxWeb Control Center.
The Session object provides a set of methods that enable the programmer to store information. You can store regular variables and arrays into the Session object, but not objects.
To store a variable in the Session object, use the SetVar method. The following script stores two variables in the Session object:
To retrieve information from the Session object, use the GetVar method:
To delete a variable from the Session object use the Remove Method:
FoxWeb typically keeps track of the Session ID by means of an HTTP cookie. Virtual all modern browsers support cookies, however it is possible for users to disable cookie support. If you want your applications to function on browsers that do not support cookies, then you will need to insert the session ID in all links pointing to FoxWeb scripts. This can be done by inserting the value of the Session.Token property in the Query String portion of all URLs.
For links this is done in the HREF clause:
For forms this is done in the ACTION clause:
A cookie is a token that the Web server embeds in a user's Web browser to identify the user. The next time the same browser requests a page, it sends the cookie it received from the Web server. Cookies circumvent the stateless nature of the HTTP protocol by allowing Web servers to store information on the user's hard disk in dedicated "cookie" files. For all intents and purposes, cookies can only be read by the domain which originally created the cookie. FoxWeb scripts can send cookies to the browser by using the SetCookie method of the Response object and then retrieve these cookies by using the GetCookie method of the Request object.
Cookies are sent to the browser via commands in the HTTP header. If FoxWeb is configured to not buffer script output, then you should set all cookies before calling the Response.Write method.
To send a cookie to the user's browser, use Response.SetCookie method. For example, to send a cookie named "UserName" with an associated value "John Doe" to the browser, use the following command:
To retrieve the value of a cookie, previously sent to the browser, use the Request.GetCookie method. Assuming that a cookie named "UserName" was sent as in the example above, the following command will return "John Doe":
In addition to the GetCookie method, FoxWeb provides the Request.CookieCount method, which returns the total number of cookies received by the server, and the Request.CookieArray method, which returns an array, containing all the cookies.
Each cookie stored on the user's Web browser has a path associated with it. When the browser requests a file stored in the same location or in a subdirectory of the path specified in the cookie, the browser automatically sends the cookie to the server. Unless the script explicitly specifies a path when setting a cookie, the browser associates the newly received cookie with the same path as the one containing the script. For example, if a FoxWeb script residing in /ContactMine sends a cookie to a browser, then each time that same browser retrieves any file residing in that directory, or one of its sub-directories, the browser will send the cookie back the server.
To specify a path for a cookie other than the default application path, you must pass the desired path to the Response.SetCookie method. The following example assigns the server root path / to a cookie called UserName. Since the server root is the highest level path on the server, this ensures that the cookie will be sent along with all subsequent requests, no matter where the requested file resides:
In the above example the Expiration Date parameter is omitted, which means that the cookie will be purged when the browser is re-started.
Note: Most Web browsers, including Netscape Navigator and Microsoft Internet Explorer, preserve the case of the cookie path. This means that if the case of the path stored with the cookie does not match the case of the path specified in the URL, the browser will not forward the cookie to the server.
Windows Web servers and FoxWeb are not case sensitive in regard to the paths contained in URLs. This means that the path /CONTACTMINE/CONTACT.FWX and /ContactMine/contact.fwx point to the same script. Browsers, on the other hand, are case sensitive. This means that if a script that was called with the first path sends a cookie to the browser without specifying a path, and also contains a link to itself using the second path, the browser will not send the cookie back to the server when the link is clicked, because the two paths do not match. The stored cookie is associated with the path /CONTACTMINE, but the requested URL is for the path /ContactMine.
To avoid this problem from happening, you must ensure that all URLs to FoxWeb scripts have the same case. Alternatively, you can always associate cookies with the server's root directory, as in the example above.