Mon approche désigne un domaine comme domaine "central" et tous les autres comme domaines "satellites".
Lorsqu'une personne 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 située sur le domaine central, ainsi qu'un élément de formulaire caché indiquant de quel domaine elles proviennent (par commodité, pour que l'utilisateur soit redirigé ensuite).
Cette page du domaine central définit ensuite un cookie de session (si la connexion s'est bien déroulée) et redirige 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 de l'URL satellite vérifie alors ce jeton pour voir s'il correspond à un jeton qui a été généré pour une session, et si c'est le cas, elle se redirige vers elle-même sans le jeton, et définit un cookie local. Maintenant, ce domaine satellite possède é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 crawler enregistre l'URL contenant ce jeton (bien que si c'était le cas, cela ne devrait pas avoir d'importance, le jeton peut être à usage unique).
Maintenant, l'utilisateur a un cookie de session à la fois dans le domaine central et dans le domaine satellite. Mais que se passe-t-il s'il visite un autre satellite ? Eh bien, normalement, il apparaît au satellite comme non authentifié.
Cependant, dans toute mon application, chaque fois qu'un utilisateur a une session valide, tous les liens vers les pages des autres domaines satellites sont accompagnés d'un ?s ou d'un &s. Je réserve cette chaîne de requête 's' pour signifier "vérifiez avec le serveur central car nous pensons que cet utilisateur a une session". Je réserve cette chaîne de requête 's' pour signifier "vérifier avec le serveur central car nous pensons que cet utilisateur a une session". En d'autres termes, aucun jeton ou identifiant de session n'est affiché sur les pages HTML, seule la lettre "s" ne permet pas d'identifier quelqu'un.
Une URL recevant une telle balise de requête 's' va, s'il n'y a pas encore de session valide, faire une redirection vers le domaine central en disant "pouvez-vous me dire qui c'est ?" en mettant quelque chose dans la chaîne de requête.
Lorsque l'utilisateur arrive au 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 un satellite le ferait après s'être connecté (voir ci-dessus). En d'autres termes, le satellite créera un cookie de session sur ce domaine et se redirigera vers lui-même pour supprimer le jeton de la chaîne d'interrogation.
Ma solution fonctionne sans script, ni support iframe. Elle nécessite l'ajout de " ?s " à toutes les URL inter-domaines où l'utilisateur n'a peut-être pas encore de cookie. J'ai pensé à un moyen de contourner ce problème : lorsque l'utilisateur se connecte pour la première fois, mettre en place une chaîne de redirections autour de chaque domaine, en plaçant un cookie de session à chaque fois. La seule raison pour laquelle je n'ai pas implémenté cette solution est qu'elle serait compliquée dans la mesure où il faudrait pouvoir définir l'ordre dans lequel ces redirections se produiraient et le moment où elles s'arrêteraient, et qu'elle vous empêcherait de vous étendre au-delà de 15 domaines environ (trop et vous vous rapprochez dangereusement de la "limite de redirection" de nombreux navigateurs et proxies).
