Net chrome cannot use session problem solution

 

Symptom:

1. The user can open the login interface, and the style is correct.
2. After entering the user name and password, the system has started to jump, but immediately prompts logon timeout.
Analysis:
1. The user can open the login interface, and the style is correct:
It is definitely not a style issue, it is not a simple interface issue.
2. After entering the user name and password, the system has started to jump, but immediately prompts logon timeout.
When this step is prompted, it indicates that the login verification has passed and the code for verifying the existence of the session has been reached. However, it must be a session before this prompt is displayed.
3. The problem arises: the session is created and the session will be lost immediately. According to the customer's environment, I also tried chrome, ie9, ie10 and so on, all of which were okay. It seems that it still has nothing to do with the browser itself. It may have something to do with the computer environment and browser configuration. Later I found that this suspicion was correct.
If you find the problem, you have to solve it. First, I went to the Internet to find some materials. One of them is similar to me.

There is a saying that makes sense:

IT shares the reasons why the asp.net chrome browser cannot use the session and solutions

The Session is implemented by the SessionId stored in the Cookie. As a result, the Cookie on the current page is not transmitted to the Upload of the Flash request. ashx, so the requested file is sent to Upload. ashx is a new Session. Of course, this Session is not logged on.

I further inquired about the Session mechanism:

Session is a server-side storage space maintained by the application server. When you connect to the server, the server generates a unique SessionID, use this SessionID as the identifier to access the Session bucket on the server. SessionID is saved to the client, and Cookie is used.
Session is a server-side storage space maintained by the application server. When you connect to the server, the server generates a unique SessionID, use this SessionID as the identifier to access the Session bucket on the server. SessionID is saved to the client and saved using cookies. When a user submits a page, the SessionID is submitted to the server to access Session data. This process requires no developer intervention. Therefore, once the Cookie is disabled on the client, the Session will also become invalid.

I enabled cookies in chrome to log on. If disabled, you cannot log on.
It seems that this problem is true.
There are three solutions available on the Internet:
A. The cookie can be used to save the session id. In this way, the browser can automatically send the id to the server according to the rules during the interaction process.
B. because the cookie can be artificially disabled, there must be other mechanisms so that the session id can still be passed back to the server when the cookie is disabled. A frequently used technology is called URL rewriting, the session id is appended to the URL path. There are two additional methods, the other is appended to the URL as a query string. The network remains in the state throughout the interaction process, and the session id must be included after the path that each client may request.
C. Another technique is form hidden fields. 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.

In asp.net, it is simpler to modify a web. config parameter:
<SessionState cookieless = "true">
You only need to configure it in this way. With this configuration, we will find that the URL we visit is changed to http: // yourserver/folder/(session ID here)/default. aspx. The SessionID on the server is written in the browser bar, which poses a certain security risk-session hijacking. In other words, someone else can copy this SessionID to access the website as your identity/session. In addition, if we write a hyperlink inside the website on the page, such as <a runat = "server" href = "~ /Test/page. aspx "> Click </a>. In this way, the page after the jump is opened in a new session, we can write <a runat = "server" href = <% = Response. applyAppPathModifier ("/test/page. aspx ") %> Click </a> to add a session ID string to the hyperlink through the ApplyAppPathModifier method of Response. This method uses a URL string as the parameter, in addition, an absolute URL embedded with session information is returned. This method can be used when the http link jumps to the https link.

IT shares the reasons why the asp.net chrome browser cannot use the session and solutions

It's ugly. I finally gave up this solution.

 

But there is another problem. I don't know if you do not:

Why can I log on to the session and enable the cookie without configuring chrome or ie9 on my machine? At first I suspected it was a security software issue, but I ruled out it all at once, because the security software will not disable cookies without manual configuration.

Only one possibility is that the operating system itself is highly secure, and the cookie cannot be used after the browser is installed. Later, the customer gradually responded to the problem and found that this guess was correct:

The operating system of the computer is windows server, and the operating system security factors such as win7, win8, and xp are relatively low. In particular, the default browser IE requires https authentication.

The problem is solved. Sometimes the problems that occur in the program are very simple and representative. In fact, you can find that there are still a lot of Tao

Supplement: The session cannot be found in Chrome and Firefox browsers for SWFUpload.

SWFUpload is a very good asynchronous Upload component, but it may cause problems when used in Chrome, Firefox and other browsers. The problem is as follows: to avoid skipping the Upload page and directly connecting to the "general processing program for receiving SWFUpload uploads" (for example, Upload. the WebShell vulnerability occurs when a request is sent. ashx implements permission control. Only login users can upload data. There is no problem in IE, but the error "user is not logged on" is reported when running in Chrome ".

After searching, it is found that because SWFUpload is uploaded by Flash, Flash will send the Cookie of the current page to Upload under IE. ashx, but Chrome and Firefox do not send the Cookie of the current page to Upload. ashx. The Session is implemented by the SessionId stored in the Cookie. As a result, the Cookie on the current page is not transmitted to the Upload of the Flash request. ashx, so the requested file is sent to Upload. ashx is a new Session. Of course, this Session is not logged on.

The idea for solving this problem is also very simple, that is, manually passing the SessionId to the server, then the server reads the SessionId and loads the Session. In fact, the solution to the problem has been provided in the SWFUpload Demo, that is, to set the post_params parameter in the SWFUpload constructor:

The code is as follows:	Copy code
Swfu = new SWFUpload ({ Post_params :{ "ASPSESSID": "<% = Session. SessionID %>"         }

 
The key-value pairs set in post_params are passed to Upload. ashx in Form, that is, SWFUpload provides an interface for adding custom request parameters to requests.
 
The above code writes the SessionId of the current page to the ASPSESSID value. After the user uploads the file, the ASPSESSID will be passed to the server. Add the following code to Application_BeginRequest of Global. asax:

The code is as follows:

Copy code

Var Request = HttpContext. Current. Request; Var Response = HttpContext. Current. Response;   Try { String session_param_name = "ASPSESSID "; String session_cookie_name = "ASP. NET_SESSIONID ";   If (HttpContext. Current. Request. Form [session_param_name]! = Null)     { UpdateCookie (session_cookie_name, HttpContext. Current. Request. Form [session_param_name]);     } Else if (HttpContext. Current. Request. QueryString [session_param_name]! = Null)     { UpdateCookie (session_cookie_name, HttpContext. Current. Request. QueryString [session_param_name]);     } } Catch (Exception) { Response. StatusCode = 500; Response. Write ("Error Initializing Session "); }

     

The UpdateCookie method is defined as follows:

The code is as follows:

Copy code

Static void UpdateCookie (string cookie_name, string cookie_value)         { HttpCookie cookie = HttpContext. Current. Request. Cookies. Get (cookie_name ); If (cookie = null) { Cookie = new HttpCookie (cookie_name ); // The code in the SWFUpload Demo is incorrect. You need to add the cookie. Expires setting. Cookie. Expires = DateTime. Now. AddYears (1 ); HttpContext. Current. Request. Cookies. Add (cookie ); } Cookie. Value = cookie_value; HttpContext. Current. Request. Cookies. Set (cookie );         }

 
Principle: when a user request arrives at ASP. net engine, the Application_BeginRequest method is called first. In the method, check whether the client has submitted the ASPSESSID. If so, write the value of ASPSESSID to the Cookie (with "ASP. NET_SESSIONID "is the Key because ASP. the SessionId is saved in ASP. Net. NET_SESSIONID "in the Cookie with the Key). After Application_BeginRequest, you can read" ASP. the value of NET_SESSIONID is restored to the Session on the page.

If the website still uses the FormsAuthentication verification of Membership, you also need to process the AUTHID according to the SessionID method, which is not mentioned in other articles about SWFUpload Bug processing.

Set the post_params parameter in the SWFUpload constructor:

The code is as follows:	Copy code
Swfu = new SWFUpload ({ Upload_url: "/AdminHT/UploadArticleImg. ashx ", Post_params :{ "ASPSESSID": "<% = Session. SessionID %> ", "AUTHID": "<% = Request. Cookies [FormsAuthentication. FormsCookieName]. Value %>" },

 
Add the following code to Application_BeginRequest of Global. asax:

The code is as follows:

Copy code

Try { String auth_param_name = "AUTHID "; String auth_cookie_name = FormsAuthentication. FormsCookieName;   If (HttpContext. Current. Request. Form [auth_param_name]! = Null)     { UpdateCookie (auth_cookie_name, HttpContext. Current. Request. Form [auth_param_name]);     } Else if (HttpContext. Current. Request. QueryString [auth_param_name]! = Null)     { UpdateCookie (auth_cookie_name, HttpContext. Current. Request. QueryString [auth_param_name]);     }   } Catch (Exception) { Response. StatusCode = 500; Response. Write ("Error Initializing Forms Authentication "); }

What should I do later? The session in the swfupload plug-in uploads files does not support the problem, because the small editor thinks this method can help us solve the problem of session loss in net.