2012-04-04 13 views
6

Estoy perdiendo ASP.NET_SessionId al cambiar de página en mi sitio. El problema ocurre en Chrome/Firefox/Safari. No sucede en IE. Es bastante extraño ... aquí está mi escenario.ASP.NET_SessionId falta

Se puede acceder a mi sitio ingresando a www.example.org o example.org en el navegador (esta es una información importante, como verá).

Ingresé example.org. Desde mi página de inicio, inicio sesión en mi sitio (nota: no estoy usando autenticación de formularios ASP.NET). Me envían a mi página de usuario predeterminada (por ejemplo, userpage.aspx). Desde esta página, hago clic en <a> que me envía a una página diferente en mi sitio. El enlace <a> está calificado (por ejemplo, http://www.example.org/page2.aspx). Cuando me envían a la nueva página, ¡mi sesión se pierde!

Por lo tanto, ejecuté Fiddler para tratar de descubrir el problema. Lo que encontré fue interesante. La etiqueta del encabezado de solicitud Referer se estaba perdiendo entre las páginas.

Estos son los pasos:

  1. Ir a example.org.
  2. Inicie sesión en example.org.
  3. Me redirigen a userpage.aspx. El Referer es http://example.org. ASP.NET_SessionId está configurado.
  4. Hago clic en <a> (por ejemplo, http://www.example.org/page2.aspx). Después de que se represente la página, se pierde ASP.NET_SessionId.

La perdida ASP.NET_SessionId se pierde consistentemente en Chrome/Firefox/Safari. Esto no sucede en IE.

Si repite los pasos anteriores sustituyendo example.org con www.example.org, ASP.NET_SessionId no se pierde. Funciona, correctamente cada vez.

¿Alguna idea de este comportamiento?

+0

en el violín es la cookie enviada en todos los casos o no? –

+0

lo que intentas en el código de página2? y estás usando el modo de estado de la sesión InProc? –

Respuesta

6

Agregar a su web.config bajo la > elemento system.web <

 
<httpCookies domain=".mysite.com" /> 

A ver si hay algún cambio en el comportamiento. Parece que los subdominios están fallando aunque, para empezar, pensé que la cookie se basaba en el dominio raíz. esto debería forzarlo de esa manera.

+0

Creo que puede estar en algo. La cookie es solo un lado de la ecuación en la administración del estado de la sesión. También está el servidor. Creo que desde la perspectiva de IIS, www.misitio.com es una aplicación diferente de solo mysite.com. Incluso si apuntan a los mismos archivos/directorios físicos, son entidades distintas, y la sesión se basa en httpcontext.current, que está vinculado al ámbito de aplicación actual. (Espero que alguien más inteligente que yo pueda decir eso mejor y verificar si estoy en lo cierto. Probablemente no. De hecho, lo estoy publicando y espero aprender). – David

+0

@DavidStratton todos existirán en el mismo grupo de aplicaciones. Todos los encabezados de host configurados apuntarán al mismo grupo de aplicaciones. En este caso, creo que el navegador simplemente no está enviando la cookie debido al dominio de la cookie (por lo que funciona según lo previsto). Lo importante aquí (que no se menciona en el OP) es si el violín muestra la cookie que se envía o no. –

+0

gracias Eso tiene sentido. – David

0

En mi caso, el siguiente era la cuestión:

En mi entorno de Visual Studio locales, el desarrollo de mi archivo "web.config" accidentalmente contenía lo siguiente:

<configuration> 
    <system.web> 
     <httpCookies requireSSL="true" /> 
    </system.web> 
</configuration> 

Desde el desarrollo de IIS Express sale en http://localhost:7561, que no es HTTPS, esta comprobación se activó para no establecer/aceptar cookies, incluida la cookie de ID de sesión.

La solución consistió simplemente en comentar la línea <httpCookies requireSSL="true" />.


Otro problema similar que podía imaginar es que el Content-Security-Policy HTML etiqueta meta, que también controls how cookies are handled, también podría estar configurado para no permitir que la cookie de ID de sesión que desea ajustar.