Session implementation and operation methods in ASP. NET

In ASP. NET, the State persistence methods include applicationstate, sessionstate, Cookie, configuration file, and cache.

 

Typical applications of applicationstate, such as storing global data.

A typical application of sessionstate, such as saving a shopping cart project.

Typical cookie applications, such as website personalization.

Typical application of the configuration file, such as saving the customer account information.

Typical applications of cache, such as storing data obtained from the database.

 

Relatively speaking, the most insecure is the cookie, because it is stored on the client and will be modified by the user. The other types are only on the server and never sent to the client. Therefore, they are secure. However,

Session hijacking may occur if you do not use the SSL (Secure Socket Layer) protocol (HTTPS is based on SSL) Because sessionid is involved.

 

Of course, the State persistence mentioned above is a general State persistence that can truly maintain the status of a specific client, only cookie and session, of course, other methods based on login users will not be mentioned.

Today, I only want to learn about the session. When I wrote the test a few days ago, the session suffered a huge loss .....

 

Session can maintain some information on the server side, and this information can be shared when a specific user redirects between different pages in a specific webapp. Therefore, this mechanism is often used to save the shopping cart information, because a user may browse different product pages on an e-commerce site, and then add products to it, the page Jump information is maintained for the same user and is implemented using session.

For the server, to identify a specific client, you must give the client an ID called sessionid. This item must be generated and sent by the server and stored on the client. There are two storage methods: client cookie and URL. This step causes the risk of session hijacking. This risk can be solved by using SSL transfer.

 

What you need to know about sessionid is that it is a 120-bit identifier generated by a module called sessionstatemodule in the HTTP request processing pipeline and generated using a private algorithm, this ensures that the value is unique and random enough (from a statistical perspective, of course ). Therefore, it can be seen from this that sessionid does not need to be concerned by developers at all. It is a problem solved by the ASP. NET service.

 

Next, the system provides a set named session, which can be read and written directly, as shown below:

 

Write:

Session ["simplestring"] = "Hello session! ";

Read from this page or the next page:

String S = session ["simplestring"]. tostring (); // You must convert the type of the Set element here.

 

It's really easy ....

 

Based on the principle of a thorough understanding of the same thing, I certainly need to understand what this session is, and where the session information is stored on the server?

1: session is a property of the httpcontext class and an object of the httpsessionstate type:

Public sealed class httpcontext: iserviceprovider

{

//...

Public httpsessionstate session {Get ;}

//...

}

 

Since it is an object of the httpsessionstate type, I will check what is available in this class and check msdn. There are many things, but I think it is interesting to see:

Session. Count indicates the number of items in the current session set.

Session. sessionid indicates the sessionid of the current client session.

Iscookieless indicates whether the current session ID is stored in a cookie or embedded in a URL.

Timeout indicates how long the current session will be stored. Because the client does not request the destruction of session data, the data will be automatically released by the server after a certain amount of time.

With this method, abandon () can immediately cancel the current session and release the space it overcomes. It is effective on the exit page and ensures that server resources are recycled as quickly as possible.

Clear () This method clears all session items without changing the current session ID.

 

2: session data is also handled by the sessionstatemodule, but it does not save session data. Data is stored in something called sessionstate provider. There are three typical provider Methods: inproc, stateServer, sqlserver.

Inproc: Set to store sessions in the process, which is the same as the storage method in ASP. This is the default value.

StateServer: Set to store sessions in independent State services.

Sqlserver: sets to store sessions in SQL Server.

 

We generally use the inproc method by default. This configuration is specified through web. config, as shown below:

 

<Sessionstate
Mode = "inproc"
Stateconnectionstring = "TCPIP = 127.0.0.1: 42424"
Sqlconnectionstring = "Data Source = 127.0.0.1; trusted_connection = yes"
Cookieless = "false"
Timeout = "20"
/>

　　

The syntax of this configuration section is as follows:

<sessionState mode="Off|InProc|StateServer|SQLServer"
              cookieless="true|false"
              timeout="number of minutes"
              stateConnectionString="tcpip=server:port"
              sqlConnectionString="sql connection string"
              stateNetworkTimeout="number of seconds"
/>

 

For more information about the two storage methods, see the following article.

 

Last learning point: when session information is unavailable.

1: The user closes and restarts the browser, and then requests the same page. Although the session is still there, the old session is no longer available because the new session ID is generated this time.

2: The user accesses the same page through another browser window. At this time, different browsers have different processing methods, and some sessions are still available and some are unavailable.

3: The session times out because there is no activity. By default, the session times out after 20 minutes of idle.

4: The session. Abandon () method is called in the program to end the session.

 

Article: http://www.cnblogs.com/rayinuk/archive/2005/01/31/99670.html