what is ASPXAUTH cookie?

问题:

While working with ASP.Net Forms Authentication I came across the .ASPXAUTH cookie. I have a couple questions:

• What is the purpose of this cookie?
• What is the location of this cookie?

回答1:

The ASPXAUTH cookie is used to determine if a user is authenticated.

As far as the location of the cookie, that depends on your browser. If you are using Firefox you can view the cookie by clicking on Tools -> Options -> Privacy. Then scroll down to the domain and expand it to see the cookie and its value. The value is encrypted using the machine key (located in the server's machine.config or web.config file) so looking at the cookie on the client won't really provide you any information. You can decrypt/view the value on the server side using:

HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];//.ASPXAUTH
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);

where authTicket has these fields:

The statement "ASPXAUTH is basically used to maintain ASP.NET Session State" is incorrect. ASP.NET issues an entirely different cookie, named ASP.NET_SessionId, to track session state.

回答2:

Actually the .ASPXAUTH cookie does not accurately tell you when the user is truly authenticated. When the user logs out of the app, the .ASPXAUTH cookie is removed from the browser. However, if you go back to the site within a short period of time (with timeout of form auth cookie), and edit the new ASP.NET_SessionId cookie's with the following:

• change "name" field from "ASP.NET_SessionId" to ".ASPXAUTH"
• change "value" from 24 char sessionID to old 448 char authentication string

After refresh you will be able to assume the identity of the authenticated user without technically re-authenticating again. (again assuming you do this within the specificied timeout stored within the .ASPXAUTH encrypted auth string)

A good blog post explains the problem in more detail. A possible solution is to couple the .ASPXAUTH with the ASP session.

回答3:

If a user's interactions with the HTML login URL have allowed the TSWPPserver to establish the user’s identity, the remote server SHOULD generate a cookie that identifies the user and allows authentication to the server. The contents of the cookie SHOULD be signed and encrypted. The specific implementation of this cookie including the signing and encryption algorithms is dependent on the implementation of the TSWPP server, because only the server is required to parse the contents of the cookie. If the server implements the cookie, then the cookie MUST be returned in an HTTP payload with a Content-Type of "application/x-msts-webfeed-login".

http://msdn.microsoft.com/en-us/library/ee920427.aspx