Fonctionnement des cookies avec les équilibreurs de charge non persistants

Nous avons une application Drupal qui utilise sso pour connecter les utilisateurs.

Nous utilisons des équilibreurs de charge classiques (ELB) AWS, AWS nous dit qu'il n'y a pas de persistance de session sur l'ELB.

Ce que j'essaie de comprendre, c'est comment les cookies fonctionnent avec non persistance sur les équilibreurs de charge classiques.

example.com DNS pointe vers l'ELB. Il y a 2 serveurs dans le pool Server1 et Server2

Ce que nous voulons, c'est que si un utilisateur accède à sa page d'accueil sur http://example.com/user/12345/disons sur le serveur 1 s'il n'est pas déjà connecté, il est redirigé vers la page sso http://example.com/user/login/sso, se connecte automatiquement et obtient un cookie SESS<hexnumber>, puis redirigé vershttp://example.com/user/12345/

Nous ne sommes pas autorisés à ajouter de serveur de sessions (redis), ce qui garantit qu'ils resteront sur le serveur 1 pour les deux redirections.

À ma connaissance, chaque fois que vous accédez à "example.com", l'utilisateur peut se retrouver sur le serveur 1 ou le serveur 2.

Ma question:

S'ils obtiennent le cookie sur server1 et sont ensuite redirigés vers server2, comment server2 saura-t-il qu'un cookie est déjà attribué à cet utilisateur sur server1?

Il me semble que je me pense en rond. Lorsque nous travaillions sur ce type de configuration dans le passé en utilisant des LB sans persistance de session, nous avons utilisé un serveur redis pour tenir les sessions et chaque demande regardait le serveur redis pour les informations de session.

Un cookie est installé dans le navigateur, pas sur un serveur. Il est limité à un domaine et, éventuellement, à un chemin spécifique dans l'URL, de sorte que tant que les deux serveurs sont accessibles par le même domaine, le cookie sera là.

Si un cookie pointe vers une session, il est nécessaire que server1 et server2 aient accès à cette session d'une manière ou d'une autre. Si les sessions ne peuvent pas être partagées entre les serveurs, vous devez forcer un utilisateur à persister sur un serveur spécifique. Cela peut être facilement accompli avec DNS et un peu de magie de réécriture d'URL:

• www.example.com pointe vers les deux serveurs.
• www1.example.com pointe uniquement vers server1
• www2.example.com pointe uniquement vers server2

À l'aide d'un ensemble de règles de réécriture simples (ish) et d'un cookie, l'utilisateur peut ensuite être verrouillé sur un serveur particulier, en veillant à ce que sa session persiste.

Voici quelques détails supplémentaires.

DNS:

• example.com A 1.1.1.1, A 2.2.2.2
• www.example.com CNAME example.com
• www1.example.com A 1.1.1.1
• www2.example.com A 2.2.2.2

Réécrire les règles:

• cookie de persistance: "backend"
• connexion initiale: "backend" non défini, définissez "backend" sur www1 ou www2, selon le serveur qui a répondu et redirigez-le vers ce serveur. Le cookie doit être défini sur le domaine "example.com", de cette façon, il sera chargé à la fois sur www1 et www2
• Si "backend" est défini, assurez-vous que sa valeur correspond à l'instance de serveur et redirigez si nécessaire.
• Assurez-vous que le cookie de session est défini dans le nom de domaine complet du serveur, à savoir www1.example.com ou www2.example.com

La logique de réécriture doit être définie sur le serveur Web lui-même. Tous les serveurs Web modernes ont des langages de réécriture très fonctionnels qui sont totalement capables de mettre en œuvre cette fonctionnalité.

Si vous ne pouvez pas utiliser une base de données de gestion de session comme Elasticache Redis (Redis pour les sessions uniquement ne devrait pas coûter plus de 15 $ par mois), alors la prochaine meilleure option est d'activer les sessions persistantes sur l'ELB;

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Cela forcera les utilisateurs à se connecter au même nœud principal tout au long de la session. Un "cookie généré par un équilibreur de charge" avec une durée de vie de 900 secondes devrait être suffisant, mais vous pouvez le modifier.