2009-06-02 12 views
11

Aunque me doy cuenta de que esto generalmente está relacionado con ataques de scripts cruzados, lo que me pregunto es cómo una sesión puede permanecer válida en múltiples subdominios pertenecientes a un único dominio (ejemplo: un usuario iniciando sesión solo una vez, y pudiendo acceder tanto a subdomain1.domain.com como a subdomain2.domain.com con la misma sesión). Creo que primero necesito entender cómo funciona, pero hasta ahora no he podido encontrar mucho que pueda ser relevante.Acceso de cookie de dominio cruzado (o sesión)

Pero, de nuevo, tal vez no estaba haciendo la pregunta correcta.

Gracias de antemano :)

Respuesta

0

Se puede establecer una cookie para un dominio específico.

En php, el método setCookie() contiene un parámetro en el que puede especificar el dominio de nivel superior, por lo que la cookie es válida para todos los subdominios. En función de sus etiquetas, veo que está trabajando en asp.net. Probablemente esto también existe para asp ...

después de un poco de búsqueda de ASP:

intente esto:

Response.Cookies("CookieName").Domain = ".mydomain.com" 

o leer this

+0

Mira el compañero de etiqueta. – Shoban

+1

euhm, lo hice ... De lo contrario, no habría escrito 'Basado en sus etiquetas' ... – Fortega

+0

Pero lo editó de nuevo (?) No veo el segundo código la primera vez ;-) – Shoban

18

sesiones Inproc no puede seguir siendo válido, sin embargo se puede codifique su aplicación web para permitir cookies en múltiples subdominios. Usted tendrá que establecer el dominio igual a:

Response.Cookies("CookieName").Domain = ".mydomain.com" 

Remember the period.

+0

No es posible establecer cookies en otro dominio. Debe estar bajo tu propio dominio. – aleemb

+5

@aleemb por supuesto, sí dije subdominios. –

+17

El título lo dice pero si lees lo que está preguntando, él claramente dice subdominios. –

2

Por defecto, todas las cookies de un sitio se almacenan juntos en el cliente, y todas las cookies se envían al servidor con cualquier solicitud a tal sitio. En otras palabras, cada página de un sitio obtiene todas las cookies para ese sitio. Sin embargo, se puede establecer el alcance de las galletas de dos maneras:

  1. limitar el alcance de las galletas a una carpeta en el servidor, lo que le permite limitar las cookies para una aplicación en el sitio.
  2. Establecer ámbito en un dominio, que le permite especificar qué subdominios en un dominio pueden acceder a una cookie.

Puede obtener más información here.

1

Los comentarios sobre la cookie que se establece para el dominio para permitir que los subdominios reciban esa cookie le dan ese lado pero lo que falta es la consistencia de la sesión.

Creo que esto es muy similar al problema de mantener el estado en servidores de una granja y la solución probablemente sea asegurar que tu sesión sea coherente en ambos sitios (si no son servidores del mismo 'sitio web') en IIS). Puede mover el almacén de sesiones a SQL Server (HOW TO: Configure SQL Server to Store ASP.NET Session State), lo que probablemente serviría para este fin, ya que cada sitio consultaría en la misma tienda al buscar los datos de sesión relacionados con la cookie que se les ha presentado.

Espero que lo lleve por el buen camino.

6

Existen bastantes formas de compartir datos de sesión o datos de cookies entre dominios. Lo más simple es compartirlo en el servidor a través de un almacén de datos compartido.Pero no harías esta pregunta si fuera así de fácil.

La otra forma de hacerlo es igualmente simple. El dominio one.com contiene algunos datos de la sesión, por ejemplo, name=aleem y id=123, y desea pasarlo al two.com. Se seguirán los siguientes pasos:

  1. hacer una llamada a two.com/api/?name=aleem&id=123
  2. two.com Cuando obtiene los datos a través de los parámetros de consulta, se crea una cookie con los datos. Esta cookie se almacenará bajo el dominio two.com.
  3. two.com se redireccionan de nuevo a la REFERER que en este caso pasa a ser one.com

Este es un escenario simplificado. El dominio two.com necesita poder confiar en one.com y no solo eso, sino que necesita saber que la solicitud es auténtica y no solo elaborada por el usuario, por lo que debe usar claves públicas/privadas para mitigar esto.

1

Si usted tiene la posibilidad de configurar un subdominio común, usted puede hacer esto:

En sus archivos html subdominio, incluyen un archivo JavaScript en la parte superior de esta manera:

<script src="http: //common.domain.com/check.asp"></script> 

en jaque .asp, busque su cookie logged_in y si no está presente, mostrar una página decir, algo así como el uso de http://common.domain.com/login.asp

<% 
if (cookie_not_found){ 
%> 
location.href = "http: //common.domain.com/login.asp"; 
<% 
} 
%> 

una vez que una persona se somete nombre de usuario, enviar vuelve al mismo login.asp y establece la cookie de sesión (que se establecerá en el dominio common.domain.com) y luego lo redirige al http://subdomain1.domain.com.

Lo que sucederá ahora es que se realizará una llamada al "common.domain.com/check.asp" incrustado, y el navegador enviará cookies para common.domain.com junto con la solicitud. Entonces sabrá si su sesión es válida o no, incluso cuando se encuentre en el subdominio1.domain.com.

Cuestiones relacionadas