Many developers never consider the concept of state before delivering applications to the web. As mentioned earlier, the Web is a stateless environment. Therefore, we should discuss what the state is and understand the methods that can avoid problems.
Accurate definition of status
In a single-user program, when creating an executable application, such as using VB to create a .exe file, you can declare a global (or Public) variable and then access it anywhere in the code. The moment value is always valid and accessible at all times the application is running.
For a traditional client/server solution, such as a system in which a client-based application accesses a server-based database engine, each client establishes a connection to the server and database application. This connection is usually established by verifying the user.
The verification process is a typical process of identifying a user, which proves whether it is a legitimate user through a combination of username and password.
Once authenticated, a connection is established between the client and the server-based application, which remains valid for all the time the user has used the application. This happens when the user registers on the fermented Windows 2000 server. Whenever an administrator uses the Active Directory Users and Computers utility (click the Directory Management item in the Administrative Tools option in the Start menu) to observe active user connections. This process is the same in many systems, such as Microsoft SQL Server.
This permanent connection means that when a user sends instructions or requests to the server, the server easily identifies each user. The same server response or any other user information can also be returned to the user directly. It is further noted that the server can store values and information related to each customer more easily and provide them to the corresponding customer when needed. Of course, server applications can have main global variables for users to access when needed.
This ability to identify requests from each client and save the values of the relevant user in memory constitutes the state. The state can be considered to represent the application's value, environment, and internal variables of the user and runs through the entire process of the application and user connection.
The importance of status
If you intend to create a Web site-based application that interacts with the user, rather than a web site that only displays independent pages, you must be able to provide a separate status for each user. This may just remember their name, or it may also be to store object references or different recordsets for each user. If you can't do this, the ASP web page can't do more, because when the page is executed, the variables and other related information in the page are destroyed. When the user requests the next page, all information provided by this page will be lost.
Therefore, it is necessary to find a way to save the status of each visitor. It is very important to be able to store global values for all users. For example, a web-style access or page click counter that does not provide each user with its own counter, and users usually want to see the total number of visitors, not just the number of visits they themselves visit. The number of visitors needs to be stored with the application-level state, not with the user-level state.
This is not a problem that has just emerged. It has existed since commercial sites occupy the web, and even earlier. So there are many traditional solutions for storing state on the web. Web site administrators want to know if visitors have visited their website before, and if so, how many times have they visited? Also visit other websites regularly. This will make it better to set its advertising goals. All of this requires a way to store information about the web page requests generated by the user during access or between each visit.
Create a status on the web
A common way to provide status between page requests and site access is through cookies. We have seen in the previous chapters how to store the corresponding values in the client's computer, which are sent together with each page request to the domain that is valid for this cookie. By checking and updating cookies with ASP, it is possible to maintain a state to some extent. The included information can be used to identify the user and then connect the user to a set of stored corresponding values.
For example, it can be detected whether a user request contains a site-specified cookie. If not included, the user is assigned a certain type of identity, specifying a number, and stored in a cookie with a long validity period. Every time the user visits this site in the future, he will be able to detect cookies and update the information contained in it. Data about the number and duration of visits can also be collected and stored on the server for future use.
But what happens if a user transfers to another computer, or deletes a cookie, or their browser refuses to receive the cookie sent to them? In this case, the state cannot be maintained because they will not be recognized next time. Now, there are many cookies on the web and most people will accept them without paying attention to it. If you open the Warn before accepting cookies option in your browser and then roam around a few large sites, you will understand the meaning.
1. Anonymous visitors and authorized visitors
If you think cookies are a bit sloppy solution, you can use a more straightforward approach. One approach that many sites use is to pop up a login dialog when a visitor clicks on a site, or when a page that requires verification of identity. Visitors must first register and obtain a certain type of username/password combination in order to allow access to the corresponding site or page.
To prove that the visitor is a known and legitimate user, a cookie placed on the visitor's computer either saves detailed registration data or a key indicating that the identity has been verified. At the same time, the visitor's detailed data is permanently saved on the server and ready to be used when accessing again. If the visitor has such a cookie in his browser, he can freely access the website because it has been verified.
If the cookie has no validity period (Expires), the value of the cookie will automatically disappear when the browser is closed and must be re-registered and verified again on the next visit. Of course, if you refuse to receive cookies or delete cookies, you can only get the registration dialog again. In this way, if it is not recognized, the site cannot be accessed.
By forcing users to register with a web server just like registering to their own network, Windows 2000's overall security performance provides IIS with stronger and safer verification capabilities. However, this can only work with browsers with Internet Explorer 3.0 and above. IIS can also use BASIC verification to allow non-Microsoft browsers to register a web server.
2. No more anonymous visitors
When using ASP on an IIS web server, users can be tracked in the current session unless the user leaves the site to another website or closes the browser. Later in this chapter, you will see how this feature is used to identify a visitor, store user's local information, and provide status. The following is a discussion of how it works compared to the already discussed solutions.
ASP and IIS jointly proposed a concept of user sessions, interacting through ASP Session objects. When each visitor first accesses an ASP web page on the server, create a new and independent session object for him, assign a session identification number to the session, and add a special encrypted version of the session identifier. Cookies are sent to customers.
The path of the cookie (see the previous chapter for description of cookie attributes) is set to the root path of the ASP application running on the server. This is likely to be on the default web site's root directory (i.e. /), but it may also be another value (see later). The Expires value is not provided in the cookie, so when the browser is closed, the cookie value disappears.
Whenever this user visits this ASP web page, the ASP will look for this cookie. Named ASPSESSIONIDxxxxxxxxx, where each x is an alphabetical character. From the ServerVariables collection shown in Figure 2-7 in Chapter 2, you can see it in the HTTP header.
However, this cookie does not appear in the Request.Cookies or Response.Cookies collection, which ASP hides, but is still saved on the browser. For each ASP web page request, the ASP must view the value. The value contained in this cookie indicates the user's session. Therefore, the content of the corresponding Session object (which has been processed in memory and always contains all values that operated during the previous page request process) can be handed over to the script in the ASP web page.
Of course, as mentioned earlier, if the client browser does not receive or supports these cookies, this processing will fail. In this case, an ASP session cannot be created and the status of this visitor is not automatically maintained.