Principle of manual Session Simulation

 

In summary, the built-in Session OF. NET is actually implemented through the Cookie mechanism. Next we will explain why this is done first, and then further verify it by comparing a. NET built-in Session instance and a manually simulated Session mechanism (with cookies.

Why?

(1) First of all, because you need to use some necessary Cookie-related knowledge, here is a brief introduction:

Ø cookies are stored on the client, so they are stored in the hands of others, so they are not very secure.

The browser can set to clear or disable cookies. Therefore, you cannot put indispensable items in cookies, but can only put dispensable items in cookies.

The server writes the Cookie to the client. When the client accesses the server (the browser remains unchanged ),Any contentThe request information will containAllCookie value.

Ø Cookies cannot boast about browsers of different brands and access each other (for example, cookies written by Chrom cannot be used by IE ).

Ø if the Cookie expiration time (Expires) is not set, the Cookie is called a session Cookie, indicating that the Cookie's life cycle is the browser session period. When the browser window is closed, the Cookie disappears, session cookies are generally stored in the memory instead of on the hard disk. If an expiration time is set, the browser saves the Cookie to the hard disk and closes the Cookie and opens the browser again, these cookies are still valid until the specified expiration time is Expires.LongestThe lifecycle is the Expires value. If the Cookie is full (the number and capacity are limited), the browser deletes the Cookie even if it does not expire.

(2) The following explains the Session storage principle of. NET:

As mentioned above, in order to maintain and transmit the status of ASP. NET, one mechanism is the above Cookie. The data written into the Cookie is stored on the client and is not secure. Therefore, you need to move the data from the client to the server, that is, Session. However, the Session does not simply store the data directly to the server memory, but creates an id-value ing table structure similar to the hash list. value refers to the data to be saved, the id is composed of ASP. A number automatically generated by. NET (ASP. NET_SessionId), that is, whenever we want to write data to the Session, ASP. NET will generate a number (ASP. NET_SessionId, which is a character string that is neither duplicated nor easily located in a pattern.) then, the numbers are bound as the data index, then, the serial number is saved to the client in the form of a Cookie, and the data is retained to the memory of the server. In this way, the ASP. NET_SessionId is sent to the server together, and the server can search its own data based on this number, and then obtain its value. This is the Session mechanism principle in ASP. NET. See the following sketch:

　　

Instance description-Analysis

The following is a small example: Write the user name to the Session during login before you can browse other pages inside the site. If you do not log on to the website, directly request the page inside the site. The Session will be detected. If it is null, the page will jump to the logon page.

Use the. NET built-in Session instance and the manually simulated Session mechanism (Cookie.

Of course, NVelocity is still used to process a small part of the page, so first add its DLL and reference it (refer to the previous two articles ). Then add the encapsulated "rendering" code, as shown in the following CommonHelper class:

Public class CommonHelper {// <summary> // use data to fill the templateName template and render and generate html, return /// </summary> /// <param name = "templateName"> </param> /// <param name = "data"> </param> // /<returns> </returns> public static string RenderHtml (string templateName, object data) {VelocityEngine vltEngine = new VelocityEngine (); vltEngine. setProperty (RuntimeConstants. RESOURCE_LOADER, "file"); vltEngine. setProperty (Runt ImeConstants. FILE_RESOURCE_LOADER_PATH, System. Web. Hosting. HostingEnvironment. MapPath ("~ /Templates "); // vltEngine. init (); VelocityContext vltContext = new VelocityContext (); vltContext. put ("TemData", data); // you can use $ data in the Template to reference Template vltTemplate = vltEngine. getTemplate (templateName); System. IO. stringWriter vltWriter = new System. IO. stringWriter (); vltTemplate. merge (vltContext, vltWriter); string html = vltWriter. getStringBuilder (). toString (); return html ;}}

. NET built-in Session instance

First, we use the Session we usually use to implement the above example and look at its storage mechanism.

Add three files: Login3.html, Login3.ashx (for Logon), and TestLogin3.ashx (for other pages inside the site ). The Code is as follows:

Login3.html source code and running interface:

<! DOCTYPE html> 






Login3.ashx:
Public class Login3: IHttpHandler, IRequiresSessionState {public void ProcessRequest (HttpContext context) {context. response. contentType = "text/html"; string UserName = context. request ["username"]; string PassWord = context. request ["password"]; // when logging in, determine whether the user name is correct (set to admin here). If the user name is correct, save it to the Session and jump to TestLogin3.ashx // otherwise, clear the input box, page unchanged if (UserName = "admin") {// Save the user name. net built-in Session context. session ["username"] = UserName; // Save the username and go to the TestLogin3.ashx page context. response. redirect ("TestLogin3.ashx");} else {string html = CommonHelper. renderHtml ("Login3.html", null); context. response. write (html) ;}} public bool IsReusable {get {return false ;}}}
　　　
TestLogin3.ashx:
Public class TestLogin3: IHttpHandler, IRequiresSessionState {public void ProcessRequest (HttpContext context) {context. response. contentType = "text/html"; // if the Session is null, it will jump to the login page if (context. session = null) {context. response. redirect ("Login3.ashx");} else {string username = (string) context. session ["username"]; // if the username object in the Session is null or does not exist, the page will jump to the login page; otherwise, it will be displayed if (string. isNullOrEmpty (username) {context. response. redirect ("Login3.ashx");} else {context. response. write (username) ;}}public bool IsReusable {get {return false ;}}}

As shown in the following figure, enter the data captured by the admin user and click "Log On". The request is Login3.ashx. The processing in the request is to save the user name to the Session, and you can see the response header, there is a Cookie writing process, and the Cookie content is ASP. NET_SessionId.


　　　　



When Login3.ashx verifies that the user name is correct, it immediately jumps to TestLogin3.ashx. For the data captured during the jump, you can see that the request header contains a Cookie, the Cookie value is the ASP stored on the client during Session writing. NET_SessionId.


　　　　



The processing in TestLogin3 is to verify whether. Session ["username"] exists. If yes, the value is taken and displayed. The process of verifying existence and obtaining the value is based on ASP. NET_SessionId in the Cookie in the request.
The above example illustrates the principle of the Session mechanism. The following uses cookies to simulate sessions for the same instance, so that you can understand it more deeply.
Manually use cookies to simulate the Session mechanism
Add four files: Login2.html, Login2.ashx (for Logon), TestLogin2.ashx (for other pages inside the site), and SessionMgr. cs (for Session Object encapsulation in. net ). The Code is as follows:
The login2.html code of login3.html is the same as that of login3.html of login2.html. The Code is as follows:
<! DOCTYPE html> 

SessionMgr. cs:
// Custom Session operation class public class SessionMgr {// Static in. when the net framework is running, a Dictionary-type object always exists // to simulate. net built-in Session Object private static Dictionary <Guid, string> testSession = new Dictionary <Guid, string> (); // write (custom) session public static void WriteSession (Guid id, string value) {testSession [id] = value;} // determine whether the id already exists (custom) session public static bool IsWriteSession (Guid id) {return testSession. keys. contains (id);} // obtain the value of the (custom) session with id public static string Get (Guid id) {return testSession [id];}

Login2.ashx:
Public class Login2: IHttpHandler {public void ProcessRequest (HttpContext context) {context. response. contentType = "text/html"; // obtain the UserName and password string UserName = context. request ["username"]; string PassWord = context. request ["password"]; // when logging in, determine whether the user name is correct (set to admin here). If the user name is correct, save it to the Session and jump to TestLogin3.ashx // otherwise, clear the input box, page unchanged if (UserName = "admin") {// key point Guid id = Guid. newGuid (); // generate a session ID. A Guid can be generated into a globally unique encoding to simulate the event. net built-in Session ASP. NET_SessionId SessionMgr. writeSession (id, UserName); // write (custom) session, bind UserName to the generated id (with SessionMgr class) HttpCookie cookie1 = new HttpCookie ("sessionid ", id. toString (); // only saves the id to the cookie, but does not save the corresponding data (UserName) context. response. setCookie (cookie1); context. response. redirect ("TestLogin2.ashx");} else {string html = CommonHelper. renderHtml ("Login2.html", null); context. response. write (html) ;}} public bool IsReusable {get {return false ;}}}


TestLogin2.ashx:
Public class TestLogin2: IHttpHandler {public void ProcessRequest (HttpContext context) {context. response. contentType = "text/html"; HttpCookie cookie = context. request. cookies ["sessionid"]; // when requesting this page, if the cookie is null, it will jump to the login page // if not empty, then the cookie value is taken as a Guid number if (cookie = null) {context. response. redirect ("Login2.ashx");} else {Guid id = new Guid (cookie. value); // determines whether the Dictionary on the server contains the id object. // If the Dictionary contains Its value, and display // otherwise jump to the login page if (SessionMgr. isWriteSession (id) {string value = SessionMgr. get (id); context. response. write (value);} else {context. response. write ("<script> alert ('No Logon! '); </Script> "); context. Response. Redirect (" Login2.ashx ") ;}} public bool IsReusable {get {return false ;}}}


In the preceding example, a Dictionary <id, value> object is used to simulate the Session object, and its id (Guid) is used to simulate the Session object. NET automatically generated number (ASP. NET_SessionId), and uses its value to simulate the data to be written into the Session.

Cookie disabling in browsers
As mentioned above, the browser can set to clear or disable cookies. The Session mechanism mentioned earlier relies on cookies. As mentioned above, when Cookie is disabled, it means that ASP. NET_SessionId cannot be returned to the server, and Session cannot be used. Is that true? The answer is definitely whether two methods are often used to deal with this situation:
URL address Rewriting:
Rewrite the Session id information of this user to the URL address. The server can parse the rewritten URL to obtain the Session id. In this way, you can use Session to record user status even if the client does not support cookies.
Hidden fields in a form
The server automatically modifies the form and adds a hidden field so that the session id can be passed back to the server when the form is submitted. For example:
　　　　
Summary
I have written related articles before, and I have learned all theories. Now, all things can be verified through code writing and browser debugging. The above is my understanding at the current stage, hoping to help you understand the Session mechanism of ASP. NET.