Quelle est votre approche de partage de cookies interdomaine préférée?

Question

Je vois que le truc iframe / p3p est le plus populaire, mais personnellement, je ne l’aime pas parce que javascript + champs cachés + cadre le fait vraiment ressembler à un travail de piratage. J'ai également rencontré une approche maître-esclave utilisant un service Web pour communiquer ( http: // www. 15seconds.com/issue/971108.htm ) et cela semble mieux car il est transparent pour l’utilisateur et robuste face à différents navigateurs.

Existe-t-il de meilleures approches et quels sont les avantages et les inconvénients de chacune?

Answer 1

Mon approche désigne un domaine en tant que domaine "central" et tous les autres en tant que domaines "satellites".

Lorsque quelqu'un clique sur un lien de connexion (ou présente un cookie de connexion persistant), le formulaire de connexion envoie ses données à une URL située dans le domaine central, ainsi qu'un élément de formulaire masqué indiquant le domaine d'origine. à partir de (juste pour la commodité, de sorte que l'utilisateur est redirigé ensuite).

Cette page du domaine central définit ensuite un cookie de session (si la connexion s'est bien déroulée), puis redirige vers le domaine à partir duquel l'utilisateur s'est connecté, avec un jeton spécialement généré dans l'URL, unique pour cette session.

La page située sur l'URL du satellite vérifie ensuite ce jeton pour voir s'il correspond à un jeton généré pour une session. Dans l'affirmative, il se redirige vers lui-même sans le jeton et définit un cookie local. Maintenant, ce domaine satellite a également un cookie de session. Cette redirection efface le jeton de l'URL, de sorte qu'il est peu probable que l'utilisateur ou un robot d'exploration enregistre l'URL contenant ce jeton (même si cela ne devrait pas avoir d'importance, le jeton peut être un jeton à usage unique).

Maintenant, l'utilisateur dispose d'un cookie de session à la fois dans le domaine central et dans le domaine satellite. Mais que faire s'ils visitent un autre satellite? Eh bien, normalement, ils sembleraient au satellite comme non authentifiés.

Cependant, tout au long de mon application, lorsqu'un utilisateur est dans une session valide, tous les liens vers des pages situées sur les autres domaines satellites sont suivis d'un? s ou & amp; s. Je réserve cette chaîne de requête pour signifier "vérifier auprès du serveur central car nous estimons que cet utilisateur a une session". C'est-à-dire qu'aucun identifiant de session ou de jeton n'apparaît sur une page HTML, mais uniquement la lettre 's' qui ne peut identifier personne.

Une URL recevant une telle balise de requête 's' fera, s'il n'y a pas encore de session valide, une redirection vers le domaine central en disant "pouvez-vous me dire de qui il s'agit?" en mettant quelque chose dans la chaîne de requête.

Lorsque l'utilisateur arrive sur le serveur central, s'il y est authentifié, le serveur central recevra simplement son cookie de session. Il renverra ensuite l'utilisateur vers le satellite avec un autre jeton à usage unique, que le satellite traitera comme le ferait un satellite après s'être connecté (voir ci-dessus). Par exemple, le satellite va maintenant configurer un cookie de session sur ce domaine et se rediriger vers lui-même pour supprimer le jeton de la chaîne de requête.

Ma solution fonctionne sans script ni assistance iframe. Il est nécessaire d’ajouter des «?» À toutes les URL inter-domaines où l’utilisateur n’a pas encore de cookie pour cette URL. J'ai effectivement pensé à un moyen de résoudre ce problème: lorsque l'utilisateur se connecte pour la première fois, configurez une chaîne de redirections autour de chaque domaine, en définissant un cookie de session pour chacun d'entre eux. La seule raison pour laquelle je ne l'ai pas implémentée, c'est que ce serait compliqué, car vous auriez besoin d'un ordre précis dans lequel ces redirections se produiraient et à quel moment arrêter, ce qui vous empêcherait de vous étendre au-delà de 15 domaines environ. (trop et vous vous approchez dangereusement de la "limite de redirection" de nombreux navigateurs et mandataires).

Answer 2

C'est une bonne solution si vous avez le plein contrôle de tous les domaines du backend. Dans ma situation, je n'ai qu'un contrôle client (javascript / html) sur l'un et un contrôle total sur un autre. Par conséquent, je dois utiliser la méthode iframe / p3p, ce qui est nul: (.

Answer 3

L'exemple de cet article me semble suspect, car vous redirigez en principe une URL qui, à son tour, renvoie des variables à votre domaine dans une chaîne de requête.

Dans cet exemple, cela signifierait qu'un utilisateur malveillant pourrait simplement accéder à http: //slave.com/return.asp?Return=blah&UID=123 " et connectez-vous sur slave.com en tant qu'utilisateur 123.

Est-ce que je manque quelque chose ou est-il bien connu que cette technique est précaire et ne doit pas être utilisée, eh bien, des choses comme celle-ci le suggèrent (faire passer l'identifiant de l'utilisateur, probablement pour rendre son identité portable).

Answer 4

@thomasrutter

Vous pourriez éviter de gérer tous les liens sortants sur les satellites (en ajoutant un "s" à la chaîne de requête) en effectuant un appel ajax pour vérifier l'état d'authentification du domaine "central" au chargement de la page. Vous pouvez éviter les appels redondants (lors des chargements de page suivants) en ne faisant qu'un seul par session.

Il serait sans doute préférable de faire la demande de vérification d’authentification côté serveur avant le chargement de la page, de manière à (a) avoir un accès plus efficace à la session, et (b) vous saurez au rendu de la page si l’utilisateur est ou non connecté (et afficher le contenu en conséquence).

Answer 5

Nous utilisons des chaînes de cookies, mais ce n'est pas une bonne solution car elles se cassent lorsqu'un des domaines ne fonctionne pas pour l'utilisateur (en raison du filtrage / des pare-feu, etc.). Les nouvelles techniques (y compris les vôtres) ne s’interrompent que lorsque le "maître" serveur qui distribue les cookies / gère les ruptures de connexion.

Notez que votre return.asp peut être utilisé de manière abusive pour rediriger vos sites vers n'importe quel site (voir this par exemple).

Answer 6

Ok, il semble que j’ai trouvé une solution, vous pouvez créer une balise de script qui charge le src du domaine sur lequel vous souhaitez configurer / obtenir des cookies ... seul le safari semble pour l’instant ne pas être capable de configurer Ie6 et FF fonctionnent bien ... encore si vous voulez seulement obtenir des cookies, ceci est une très bonne approche.

Answer 7

Vous devez également valider les informations de session actives sur les domaines b, c, d, ... de cette façon, vous ne pourrez vous connecter que si l'utilisateur s'est déjà connecté au domaine a.

Answer 8

Ce que vous faites est sur le domaine recevant les variables, vous vérifiez également l'adresse du référent afin que vous puissiez confirmer que le lien provient de votre propre domaine et non de quelqu'un qui tape simplement le lien dans la barre d'adresse. Cette approche fonctionne bien.