Web state Management Analysis for ASP application design

Many developers have never considered the concept of State before transferring an application to the Web. As mentioned earlier, the web is a stateless environment. So you should explore what states are and how you can avoid problems. Exact definition of State

In a single-user program, when you create an executable application, such as using VB to create an. exe file, you can declare a global (or public) variable and access it anywhere in your code. At all times the application runs, the time value is always valid and accessible.

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 the database application. This connection is usually established by validating the user's methods.

The validation process is a typical process of identifying a user, using a combination of username and password to prove whether it is a legitimate user.

Once authenticated, a connection is established between the client and the server-based application, which remains in effect for all the time the user uses the application. This happens when the user registers on the yeast Windows 2000 Server. Whenever an administrator uses the Active Directory Users and Computers utility (click Directory Management in the administrative Tools option on the Start menu) Item), you can observe the active user connection. 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 a server, the server can easily identify each user. The same server's response or any other user's information can also be returned directly to the user. It is further noted that the server can easily store the values and information associated with each customer and provide it to the appropriate customer when needed. Of course, a server application can have a primary global variable to make it accessible to users when they need it.

This ability to recognize each client's request and hold the value of the associated user in memory constitutes a state. You can think of the state as representing the value of the application, the environment, and the user's internal variables, and throughout the process of connecting the application and the user.

The importance of the state

If you plan to create web-based applications that interact with users, rather than just Web sites that display stand-alone pages, you must be able to provide a separate state for each user. This may be just remembering their names, or you might want to store an object reference or a different recordset for each user. If you can't do this, the ASP Web page can't do much more, because when the page executes, the variables and other related information in the page are corrupted. When the hired user requests the next page, all the information provided by this page will be lost.

Therefore, you need to find a way to save the status of each visitor. It is important to be able to store global values for all users. For example, a web-style access or page hit counter, which does not provide its own counters for each user, often wants to see the total number of visitors, not just the number of times they have visited themselves. The number of visitors needs to be stored with the application-level state, not with the user-level state.

This is not an emerging problem, since commercial sites occupy the web, already exist, even earlier. So there are a lot of traditional solutions for storing state on the web. Web site administrators want to know if visitors have visited their sites before, how many times have they visited them? Also regularly visit other sites and so on. This will better set its advertising goals. All of these require a way to store information about the Web page requests or between each visit that the user generated during the visit.

Create a state on the web

A common way to provide state between page requests and site access is through cookies. As we have seen in the previous chapters, how to store values in the client's computer that are sent to the domain that is valid for this cookie with each page request. By checking and updating cookies with ASP, you can maintain a state in some way. You can use the information that is included to identify the user, and then connect the user to a collection of stored corresponding values.

For example, you can detect whether a user request contains a site-specified cookie. If not, assign the user a certain type of identity, indicating a quantity and stored in a cookie with a long validity period. After each visit to the site, the user can detect the cookie and update the contained information. You can also collect data about the number and duration of visits and store them on the server for future use.

But what happens if a user moves to another computer, deletes a cookie, or their browser refuses to receive a cookie sent to them? In this case, the state cannot be maintained because the next time they do not recognize them, there are many cookies on the web, and most people will accept them without notice. If you open the "Warn before accepting cookies" option in your browser, and then roam through several large sites, you'll see what that means.

1. Anonymous and authorized audiences

If you think cookies are a somewhat sloppy solution, you can use a more straightforward approach. One way many sites adopt is when a visitor clicks on a site, or clicks on a page that requires authentication, a dialog box pops up. Visitors must first register to obtain a combination of some type of username/password to allow access to the appropriate site or page.

To verify that the visitor is a known and legitimate user, a cookie placed on the visitor's computer, it either saves the registered details, or a "key" that indicates that the identity has been authenticated. At the same time, the visitor's detailed data is permanently stored on the server and ready to be accessed again. If a visitor has such a cookie in their browser, he is free to visit the site because it has been validated.

If the cookie has no validity period (Expires), the value of the cookie disappears automatically when the browser is closed, and must be re-register and validated again on the next visit. Of course, if you refuse to receive a cookie or delete a cookie, you can only get the Registration dialog box again. In this way, if you are not recognized, you cannot access the site.

By forcing users to register to a Web server as if they were registered with their own network, the overall security of Windows 2000 provides a stronger and more secure authentication capability for IIS. However, this can only work with Internet Explorer 3.0 and version of the browser. IIS can also use Basic authentication 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 Web site or closes the browser. Later in this chapter, you will see how to use this feature to identify a visitor, store the local information for a user, and provide status. The following is a discussion of how it works, compared to the solutions that have been discussed.
ASP and IIS together propose the concept of a user session, which interacts with the ASP Sessions object. When each visitor first accesses an ASP page on the server, creates a new and separate session object for him, assigns a session identification number to the session, and sends a cookie of the specially encrypted version containing the session identifier to the customer.

The path to the cookie (refer to the previous section for a description of the cookie property) is set to the root path of the ASP application running on the server. This is likely to be the root of the default Web site (that is, "/"), but it may also be a different value (see later). The expires value is not provided in the cookie, so the cookie value disappears when the browser is closed.

Whenever this user accesses the ASP page, the ASP will look for the cookie. Named Aspsessionidxxxxxxxx, where each x is an alphabetic character. From the ServerVariables collection shown in chapter 2nd Figure 2-7, you can see it in the HTTP header.

However, the cookie does not appear in the Request.Cookies or Response.Cookies collection, and the ASP hides it, but it is still stored on the browser. For each ASP Web page request, the ASP has to view the value. This cookie contains a value that indicates the user's session. As a result, the contents of the corresponding Session object, which is processed in memory and that always contain all the values that were manipulated during the previous page request, can be transferred to the script in the ASP Web page.

Of course, as mentioned earlier, this processing will fail if the client browser does not receive or support these cookies. In this case, you cannot create an ASP session, and the status of the visitor is not automatically maintained.