Client-side solution for session object Invalidation _asp Foundation

The Session object for ASP (Active Server Pages) technology is used to store private information for users during the conversation. Variables and objects defined in the current user's session object can be shared between pages, but cannot be accessed by other users in the application, so you can use the session object to save and track the user's state information when developing a network application using ASP.

The session object has a very important attribute: Timeout, which is used to set the time when the session object can remain inactive (the default value is 20 minutes) before it is freed. When the time value set by the Timeout property is exhausted, the session resource is freed. The session object is destroyed by the timeout property, which avoids the unrestricted generation of the session object in the server and protects the server resources. However, in the actual network development, the application process can not be completed normally due to the failure of the session object and the loss of user state information.

While the policy of releasing resources using the timeout attribute is for the purpose of protecting the server, the unpredictable failure of the session object is a drawback to the development of the application. Therefore, in the development of real application, the problem of Session object invalidation must be solved.

　　The traditional way of solving

The existing solution is to use the server-side method to solve the session object invalidation problem. Typical processing methods are divided into two main categories: processing before failure and processing after failure.

Before the expiration of the processing is the session of the object has not been invalidated, the variables such as the transfer of processing, to prevent prevention. A typical workaround is to set a timer in the application, trigger the timer 5 minutes before the session object expires, and then reset the individual variables and objects for the session object. This method increases the additional load on the server because the timer must be maintained on the server side in real time, and the program must be guaranteed to be active throughout the session.

After the expiration of the processing means that the session object after the expiration, immediately prompt the user to handle. A typical workaround is to save the breakpoint on the server side after the session object expires, and prompt the user to log on again to continue with the work. This approach is simple to implement, but is often complained and blamed by end users because of the incomplete automatic recoverability of breakpoints and the complexity of the process of re-logon.

In view of the defects of the above two kinds of solutions, the author combines the characteristics of cookie object in programming practice, and uses session object and cookie object to jointly access the conversation-level variables in the client, which avoids the additional demand for server resources and solves the problem that the breakpoint cannot be automatically restored. It also eliminates the hassle of having to log in again.

　　New ways to solve the problem

A cookie object is a small packet of information that is used to store data about the current user, which can be passed between the browser and the Web server. In Web applications, cookies provide a mechanism for tracking and recording each user's location. One of the most common uses of cookies is to save the time and date of the last Web page visited and the URLs visited.

Typically, the cookie object is stored as a file in the Cookies subdirectory in the client Windows system directory. The information data stored in the cookie object can be saved for a long time, so you can back up the session-level variable in the cookie object, and then automatically recover the breakpoint by retrieving and leveraging the information in the cookie object after the sessions object expires.

The cookie object has several properties:

Expires: Sets the date on which the cookie object expires;

Domain: The delivery of a cookie object is determined to be a member determined only by the Domain attribute;

Path: Determines the cookie object routing path;

Secure: Make sure the cookie object is secure;

HasKeys: Returns whether the cookie object contains multiple values.

If you do not explicitly define the Expires property of the cookie object, the cookie object expires at the end of the user session.

In ASP, the object is read and written through the request collection and the response collection. The syntax for writing variables to a cookie object is as follows:

Response.Cookies (cookie) [(Key) |. Attribute] = value

Where the cookie is the cookie file name, key indicates a dictionary element, attribute is a specific property of the cookie, value is the values that are assigned to the cookie. For example, to create a cookie called Myhobby and assign its value to: basketball, use the following syntax:

<%response.cookies ("myhobby") = "basketball"%>

The method for reading cookie objects on a client machine is as follows:

Request.Cookies (cookie) [(Key) |. Attribute

Where the cookie is the name of the requested cookie, key is the sub-keyword value subscript, attribute is used to indicate the cookie property. For example: To extract information from a cookie called Myhobby and write its value to a page, use the following syntax:

<% request.cookies ("Myhobby")%>

Note that you cannot write information to a cookie object after the HTTP page header information has been sent to the requesting browser. In other words, you cannot send cookie information to the browser until any HTML identifier is sent to the browser.

　　Concrete implementation

The following is the implementation of a chat room based on ASP technology to describe how to deal with the failure of Session object variables.

Initial session-level variable before user logon: UserName (for storing login username).

<% session ("UserName") = ""%>

Initializing a Cookie Object

<% response.cookies ("UserName") = ""%>

When the user logs on, set the session-level variable and back up to the client cookie object.

<%username=trim (Request.for ("UserName"))%>

<% session ("UserName") =username%>

To back up a session-level variable to a client cookie object

<% response.cookies ("UserName") =username%>

When the user speaks, read the session-level variable, and if the variable is invalidated, restore the property value of the session-level variable by reading the cookie object.

<% username=session ("UserName")%>

Retrieves the client cookie object if the variable is invalidated

<% if Username= "" then%>

<% username=request.cookies ("UserName")%>

<% if Username= "" then%>

If the user enters the chat room without logging on, the Cookie object property value is empty. At this point, prompt the user for an error and turn to the user login page

<% Response.Redirect "error.html"%>

<% Else%>

Recovering the session-level variable from a cookie object

<% session ("UserName") =username%>

<% End If%>

<% End If%>

Clears session-level objects and cookie objects when the user exits the chat room.

<% session ("UserName") = ""%>

Clears the Cookie object property value to prevent users from entering the chat room without logging in

<% response.cookies ("UserName") = ""%>

The above code runs through the Windows NT 4.0+iis 4.0+ie 5.0 environment.

　　Summary

The method that session object and cookie object combine to access conversational-level variables at client is simple and practical, and can effectively avoid the problem of user's forced login, so it is a good way to solve the failure of sessions object.