Introduction to ASP Programming (8): Built-in object Session

In addition to objects used to send (Response), receive and process data (request), and server access (Server), ASP objects also have some very practical objects that mark Active Server applications (Application) and single user information (Session).

Session Object

This object accounts for a considerable proportion of ASP usage. Since web pages are a stateless program, it is impossible to know the user's browsing status. In ASP, the user's private data variables are recorded through the Session object to confirm when the user makes a request to the server again. When the user jumps between the program's web pages, the variables existing in the Session object will not disappear.

These are really important functions, especially those that must be used by systems with members. For example, the member's login account, time, status, and many real-time data recorded (such as the shopping system records the products in the user's shopping basket), this information is privately needed by each user, and usually developers use Session records to process it.

Session in ASP is composed of cookies, and the server transmits all data recorded in the session to the user's browser in the form of cookies. Usually, browsers will save these cookies. Whenever the user clicks on the link and connects it to the server again, the browser will pass these cookies back to the server for processing: this is the operating principle of Session. From this we can see that the session status Session is only reserved in browsers that support cookies. If the customer turns off the cookie option Session will not work.

1. Session.SessionID

The SessionID property returns the user's session identity. When creating a session, the server generates a separate identity for each session, and the session identity is returned as the long shaping data type. In many cases SessionID can be used for WEB page registration statistics.

This property can solve a problem of control over the user. The main function of this problem is that when a member logs in to a certain website, when a member is viewing this module, another person logs in with the same member name, he cannot browse this module: that is, a member name can only browse this module one person at the same time.

Control is achieved by using member names (assuming UserID, unique) and SessionID. When a member logs in, give the member a Session record of the login status such as: Session("Status")="Logged", and write the Session.SessionID of the member to the database. When he wants to browse this module, he first determines whether it is logged in. If he has logged in, then determines whether its SessionID is the same as the database record. If it is different, it cannot be accessed.

In this way, when another user logs in with the same member name, the new SessionID is recorded in the database, and the former cannot pass the check when accessing this module. This enables a member name to browse a certain module by one person at the same time. This function has a special effect on some paid websites. It prevents the problem of one member name to browse multiple people and protects the company's interests.

2. Session.TimeOut