¿Cuál es su enfoque favorito para compartir cookies entre dominios?

Question

Veo que el truco iframe / p3p es el más popular, pero personalmente no me gusta porque javascript + campos ocultos + marco realmente hacen que parezca un trabajo de pirateo. También me he encontrado con un enfoque maestro-esclavo que utiliza el servicio web para comunicarse ( http: // www. 15seconds.com/issue/971108.htm ) y parece mejor porque es transparente para el usuario y es robusto frente a diferentes navegadores.

¿Hay mejores enfoques y cuáles son los pros y los contras de cada uno?

Answer 1

Mi enfoque designa un dominio como dominio 'central' y cualquier otro como dominio 'satélite'.

Cuando alguien hace clic en el enlace 'iniciar sesión' (o presenta una cookie de inicio de sesión persistente), el formulario de inicio de sesión finalmente envía sus datos a una URL que se encuentra en el dominio central, junto con un elemento de formulario oculto que indica de qué dominio proviene desde (solo por conveniencia, para que el usuario sea redirigido nuevamente).

Esta página en el dominio central luego procede a configurar una cookie de sesión (si el inicio de sesión fue bien) y redirige de nuevo a cualquier dominio desde el que el usuario inició sesión, con un token especialmente generado en la URL que es única para esa sesión.

La página en la URL del satélite luego verifica ese token para ver si corresponde a un token que se generó para una sesión, y si es así, se redirige a sí mismo sin el token y establece una cookie local. Ahora ese dominio satelital también tiene una cookie de sesión. Esta redirección borra el token de la URL, por lo que es poco probable que el usuario o cualquier rastreador registre la URL que contiene ese token (aunque si lo hicieran, no debería importar, el token puede ser un token de un solo uso).

Ahora, el usuario tiene una cookie de sesión tanto en el dominio central como en el dominio satelital. Pero, ¿y si visitan otro satélite? Bueno, normalmente, parecerían al satélite como no autenticados.

Sin embargo, en toda mi aplicación, cada vez que un usuario se encuentra en una sesión válida, todos los enlaces a páginas en los otros dominios satelitales tienen un? s o & amp; s agregado a ellos. Reservo la cadena de consulta de esta 's' para que signifique '' consultar con el servidor central porque consideramos que este usuario tiene una sesión ''. Es decir, no se muestra ningún identificador de sesión o token en ninguna página HTML, solo la letra 's' que no puede identificar a alguien.

Una URL que reciba una etiqueta de consulta de este tipo 's', si aún no hay una sesión válida, realizará un redireccionamiento al dominio central que dice "¿puedes decirme quién es?" poniendo algo en la cadena de consulta.

Cuando el usuario llega al servidor central, si está autenticado allí, el servidor central simplemente recibirá su cookie de sesión. Luego enviará al usuario de regreso al satélite con otro token de un solo uso, que el satélite tratará tal como lo haría un satélite después de iniciar sesión (ver arriba). Es decir, el satélite ahora configurará una cookie de sesión en ese dominio y lo redireccionará a sí mismo para eliminar el token de la cadena de consulta.

Mi solución funciona sin script ni soporte de iframe. Requiere que se agregue '? S' a cualquier URL de dominio cruzado donde el usuario aún no tenga una cookie en esa URL. Pensé en una forma de evitar esto: cuando el usuario inicia sesión por primera vez, configure una cadena de redireccionamientos alrededor de cada dominio, configurando una cookie de sesión en cada uno. La única razón por la que no he implementado esto es porque sería complicado ya que necesitaría poder establecer un orden establecido en el que se realizarían estos redireccionamientos y cuándo detenerse, y evitaría que se expanda más allá de 15 dominios más o menos (demasiados más y te acercas peligrosamente al 'límite de redireccionamiento' de muchos navegadores y servidores proxy).

Answer 2

Esa es una buena solución si tiene el control total de todos los dominios backend. En mi situación, solo tengo control de cliente (javascript / html) en uno y control total en otro, por lo tanto, necesito usar el método iframe / p3p, que apesta :(.

Answer 3

El ejemplo en ese artículo me parece sospechoso porque básicamente redirige a una url que, a su vez, devuelve variables a su dominio en una cadena de consulta.

En el ejemplo, eso significaría que un usuario malintencionado podría simplemente navegar a http: //slave.com/return.asp?Return=blah&UID=123 " e iniciar sesión en slave.com como usuario 123.

¿Me estoy perdiendo algo, o es bien sabido que esta técnica es insegura y no debería usarse para, bueno, cosas como ese ejemplo sugiere (pasar la identificación del usuario, presumiblemente para hacer que la identidad sea portátil).

Answer 4

@thomasrutter

Puede evitar tener que administrar todos los enlaces salientes en los satélites (agregando " s " a querystring) haciendo una llamada ajax para verificar el dominio 'central' para el estado de autenticación en la carga de la página. Puede evitar llamadas redundantes (en cargas de página posteriores) haciendo solo una por sesión.

Podría decirse que sería mejor hacer la solicitud de verificación de autenticación del lado del servidor antes de cargar la página para que (a) tenga un acceso más eficiente a la sesión, y (b) sepa en la página si el usuario está o no ha iniciado sesión (y muestra el contenido en consecuencia).

Answer 5

Usamos el encadenamiento de cookies, pero no es una buena solución ya que se rompe cuando uno de los dominios no funciona para el usuario (debido a filtros / cortafuegos, etc.). Las técnicas más nuevas (incluida la suya) solo se rompen cuando el "maestro" servidor que distribuye las cookies / gestiona interrupciones de inicio de sesión.

Tenga en cuenta que se puede abusar de su return.asp para redirigir a cualquier sitio (consulte esto por ejemplo).

Answer 6

Ok, parece que he encontrado una solución, puede crear una etiqueta de script que cargue el src del dominio en el que desea establecer / obtener cookies ... solo Safari hasta ahora parece no poder ESTABLECER cookies, pero Ie6 y FF funcionan bien ... aún si solo desea OBTENER cookies, este es un muy buen enfoque.

Answer 7

También debe validar la información de sesión activa en los dominios b, c, d, ... de esta manera solo puede iniciar sesión si el usuario ya ha iniciado sesión en el dominio a.

Answer 8

Lo que haces es en el dominio que recibe las variables, también verificas la dirección de referencia para que puedas confirmar que el enlace proviene de tu propio dominio y no de alguien que simplemente escribe el enlace en la barra de direcciones. Este enfoque funciona bien.