Quelle est votre approche de partage de cookies interdomaine préférée?
Je vois que l'astuce iframe/p3p est la plus populaire, mais personnellement je ne l'aime pas parce que javascript + champs cachés + cadre font vraiment ressembler à un travail de hack. Je suis également tombé sur 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 il est robuste contre différents navigateurs.
Existe-t-il de meilleures approches et quels sont les avantages et les inconvénients de chacune?
Mon approche désigne un domaine comme domaine "central" et tous les autres comme domaines "satellite".
Lorsque quelqu'un clique sur un lien de connexion (ou présente un cookie de connexion persistant), le formulaire de connexion envoie finalement ses données à une URL qui se trouve sur le domaine central, avec un élément de formulaire caché indiquant de quel domaine il provient (juste pour plus de commodité, l'utilisateur est redirigé par la suite).
Cette page du domaine central procède ensuite à la définition d'un cookie de session (si la connexion s'est bien passée) et à la redirection vers le domaine à partir duquel l'utilisateur s'est connecté, avec un jeton spécialement généré dans l'URL qui est unique pour cette session.
La page à l'URL du satellite vérifie ensuite ce jeton pour voir s'il correspond à un jeton qui a été généré pour une session, et si c'est le cas, 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 (bien que s'ils le faisaient, cela ne devrait pas avoir d'importance, le jeton peut être un jeton à usage unique).
Désormais, l'utilisateur dispose d'un cookie de session à la fois dans le domaine central et dans le domaine satellite. Mais qu'en est-il s'ils visitent un autre satellite? Eh bien, normalement, ils apparaissent au satellite comme non authentifiés.
Cependant, tout au long de mon application, chaque fois qu'un utilisateur est dans une session valide, tous les liens vers des pages sur les autres domaines satellites sont accompagnés d'un? S ou & s. Je réserve cette chaîne de requête pour signifier "vérifier avec le serveur central car nous estimons que cet utilisateur a une session". Autrement dit, aucun jeton ou identifiant de session n'est affiché sur une page HTML, uniquement la lettre "s" qui ne peut pas identifier quelqu'un.
Si une URL ne reçoit pas encore de session valide, une URL recevant une telle balise de requête fera 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 au satellite avec un autre jeton à usage unique, que le satellite traitera comme le ferait un satellite après s'être connecté (voir ci-dessus). C'est-à-dire que le satellite va maintenant installer 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 support iframe. Il nécessite que "?" Soit ajouté à toutes les URL interdomaines où l'utilisateur peut ne pas encore avoir de cookie à cette URL. J'ai pensé à un moyen de contourner cela: 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 sur chacun. La seule raison pour laquelle je n'ai pas implémenté cela, c'est que ce serait compliqué dans la mesure où vous auriez besoin d'avoir un ordre défini dans lequel ces redirections se produiraient et à quel moment s'arrêter, et vous empêcherait d'étendre au-delà de 15 domaines environ. (trop et vous devenez dangereusement proche de la "limite de redirection" de nombreux navigateurs et proxys).
C'est une bonne solution si vous avez le contrôle total de tous les backend de domaines. Dans ma situation, je n'ai que le contrôle client (javascript/html) sur un, et le contrôle total sur un autre, donc je dois utiliser la méthode iframe/p3p, qui aspire :(.
@thomasrutter
Vous pouvez éviter d'avoir à gérer tous les liens sortants sur les satellites (en ajoutant "s" à la chaîne de requête) en effectuant un appel ajax pour vérifier le domaine "central" pour le statut d'authentification au chargement de la page. Vous pouvez éviter les appels redondants (lors des chargements de pages suivants) en n'en effectuant qu'un 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 afin que (a) vous ayez un accès plus efficace à la session, et (b) vous sachiez lors du rendu de la page si l'utilisateur est connecté ou non ( et afficher le contenu en conséquence).
L'exemple de cet article me semble suspect, car vous redirigez essentiellement vers une URL qui, à son tour, retransmet des variables à votre domaine dans une chaîne de requête.
Dans l'exemple, cela signifierait qu'un utilisateur malveillant pourrait simplement accéder à http://slave.com/return.asp?Return=blah&UID=12 "et être connecté sur slave.com en tant qu'utilisateur 123.
Suis-je en train de manquer quelque chose, ou est-il bien connu que cette technique n'est pas sûre et ne devrait pas être utilisée pour, eh bien, des choses comme cet exemple le suggère (en passant les identifiants d'utilisateur, probablement pour rendre son identité portable).
Vous devez également valider les informations de session actives par rapport aux domaines b, c, d, ... de cette façon, vous ne pouvez vous connecter que si l'utilisateur s'est déjà connecté au domaine a.
Nous utilisons le chaînage des cookies, mais ce n'est pas une bonne solution car il casse lorsque l'un des domaines ne fonctionne pas pour l'utilisateur (en raison du filtrage/pare-feu, etc.). Les techniques plus récentes (y compris la vôtre) ne se cassent que lorsque le serveur "maître" qui distribue les cookies/gère les connexions se casse.
Notez que votre return.asp peut être utilisé abusivement pour rediriger vers n'importe quel site (voir this par exemple).
Ok, il me semble avoir trouvé une solution, vous pouvez créer une balise de script qui charge le src du domaine sur lequel vous souhaitez définir/obtenir des cookies ... seul safari jusqu'à présent ne semble pas être en mesure de définir des cookies, mais Ie6 et FF fonctionne bien ... toujours si vous voulez seulement obtenir des cookies, c'est une très bonne approche.