La cookie ASPXAUTH se utiliza para determinar si un usuario está autenticado.
En cuanto a la ubicación de la cookie, eso depende de su navegador. Si está utilizando Firefox, puede ver la cookie haciendo clic en Herramientas -> Opciones -> Privacidad. Luego, desplácese hacia abajo hasta el dominio y expándalo para ver la cookie y su valor. El valor se cifra con la clave de la máquina (ubicada en el archivo machine.config o web.config del servidor), por lo que mirar la cookie en el cliente no le proporcionará realmente ninguna información. Puede descifrar / ver el valor en el lado del servidor usando:
HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];
FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
donde authTickettiene estos campos:
La declaración "ASPXAUTH se utiliza básicamente para mantener el estado de sesión de ASP.NET" es incorrecta. ASP.NET emite una cookie completamente diferente, denominada ASP.NET_SessionId, para rastrear el estado de la sesión.
Application_PostAuthenticateRequestel Request.IsAuthenticated es cierto, pero .ASPXAUTH no el valor en mi HttpContext.Current.Request.Cookies. Yo uso sessionState.En realidad, la cookie .ASPXAUTH no le dice con precisión cuándo el usuario está realmente autenticado. Cuando el usuario cierra la sesión de la aplicación, la cookie .ASPXAUTH se elimina del navegador. Sin embargo, si regresa al sitio dentro de un período corto de tiempo (con el tiempo de espera de la cookie de autenticación del formulario) y edita la nueva cookie ASP.NET_SessionId con lo siguiente:
Después de la actualización, podrá asumir la identidad del usuario autenticado sin necesidad de volver a autenticarse técnicamente. (nuevamente asumiendo que hace esto dentro del tiempo de espera específico almacenado dentro de la cadena de autenticación cifrada .ASPXAUTH)
Una buena publicación de blog explica el problema con más detalle. Una posible solución es acoplar el .ASPXAUTH con la sesión ASP.
fuente
Si las interacciones de un usuario con la URL de inicio de sesión HTML han permitido que TSWPPserver establezca la identidad del usuario, el servidor remoto DEBE generar una cookie que identifica al usuario y permite la autenticación en el servidor. El contenido de la cookie DEBE estar firmado y cifrado. La implementación específica de esta cookie, incluidos los algoritmos de firma y cifrado, depende de la implementación del servidor TSWPP, porque solo se requiere que el servidor analice el contenido de la cookie. Si el servidor implementa la cookie, la cookie DEBE devolverse en una carga útil HTTP con un tipo de contenido de "application / x-msts-webfeed-login".
http://msdn.microsoft.com/en-us/library/ee920427.aspx
fuente