|
|
As discussed, websites make use of the Application object to store application-specific data. In a similar way, web pages make use of the Session object to store track information on a per-user basis. A website, for example, might use the Session object to simplify user access to pages that require the user to log into the site. To do so, the site may, for example, display a login screen that prompts the user to enter a username and password. After the user successfully logs into the system, the site may assign a unique identifier to a Session object variable that scripts on other pages can use to determine the user’s identity.
The Session object will exist while the user is within the site’s web pages or until the object has been in existence beyond the timeout duration the programmer assigned the object. (Timeouts control the maximum amount of time the object can exist.) Should a user leave the website and later return, the user’s previous Session object will no longer be valid. At that point, the user would create a new session with its own new session data.
To store and retrieve session information, an active server page uses statements similar to the following:
Session("VariableName") = "Some value" SomeVariable = Session("VariableName")
For example, the following statements illustrate how an active server page might store a variable named UserIdentifier within the Session object:
Session("UserIdentifier") = Username & "123" & Now()
Later, a script can retrieve the UserIdentifier variable’s value as follows:
User = Session("UserIdentifier")
The following active server page, SessionDemo.asp, uses the Session object to store information about the user within the Session object. The page then creates a link to the active server page ShowSession.asp that retrieves and displays the Session object’s variables, as shown in Listing 5.8.
Listing 5.8 SessionDemo.asp
<html> <body> <% Session("StoredAt") = Now() Session("SessionID") = "ABC123" Session("Chapter") = "5" Response.Write("Session data stored") %> <br> <a href="ShowSession.asp">Link to ShowSession</a> </body> <html>
As you can see, the code uses the Session variable to store the data and then creates a link to the ShowSession.asp file, whose statements are shown in Listing 5.9.
Listing 5.9 ShowSession.asp
<html> <body> <% Response.Write("StoredAt contains " & Session("StoredAt") & "<br>") Response.Write("SessionID contains " & Session("SessionID") & "<br>") Response.Write("Chapter contains " & Session("Chapter") & "<br>") %> </body> <html>
In this case, the active server page simply retrieves and then displays the specific Session variable values. If you use your browser to open the SessionDemo.asp active server page, your browser will display a message stating the Session variables have been defined and a link to the SessionDemo.asp page. If you click the link, your browser will display a page that contains the Session variable values, as shown in Figure 5.5.
Figure 5.5: Displaying Session variables within an active server page
If you right-click the link to the SessionDemo.asp page and open multiple windows that display the page’s output, you will find that each window displays the same session data, as shown in Figure 5.6. That’s because, behind the scenes, active server pages use information stored in a cookie on the user’s hard drive that contains the ID number that identifies the session. Because each window you open sends the same cookie information to the page, each web server will use the same session ID for each window, and will thus display the same data for each.
The statements in Listing 5.10 implement the ShowSession.asp active server page.
Listing 5.10 ShowSession.asp
<html> <body> <% Response.Write("StoredAt contains " & Session("StoredAt") & "<br>") Response.Write("SessionID contains " & Session("SessionID") & "<br>") Response.Write("Chapter contains " & Session("Chapter") & "<br>") %> </body> <html>
Figure 5.6: Displaying active server page session data from the same client PC
As discussed, to store session information, active server pages make use of a cookie that contains the session identifier that the page stores on the user’s hard disk. One problem with the use of the Session object in traditional active server pages is that if a user has disabled cookies, the page cannot store the session data.
The .NET environment changes the Session-object model. Each time a user starts a session, the server assigns a globally unique identifier (GUID), a 128-bit value, to a new session that the server returns to the client and which the server stores (either within memory or within a database). The server returns the session identifier to the client program using a cookie (which the client can store in memory or which the client could store on disk).
Before a web service can support session operations, the service must be able to exchange cookie data with the server as discussed in the next section.
Within the traditional active-server-page model, the use of session-based data was limited by three key factors. First, because the session data is based on cookies, a user who disabled cookies within his or her browser also disabled support for session-based data. Second, because the web server maintained the Session-object values, should the server fail, or be restarted, existing session-based data was lost. Also, because the session data resided on a specific server, applications could not migrate users to different servers within a server farm.
As you have seen, .NET applications (because they manage the cookie data) can exchange session-based data regardless of whether or not a user disables cookies within his or her browser. Next, because the .NET environment removes the storage of session data from the web server, should the server fail, session data is not lost. Further, the session data is free to move with the client should the client move to a different server in a web farm.
.NET programs (and web services) that use session data can use the config.web file to configure session-state information, such as timeout information, database settings, and more. The following statements illustrate the contents of a typical <sessionstate> entry within a config.web file:
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false" timeout="20" />
|
|