У нас есть приложение Drupal, которое использует sso для входа пользователей.
Мы используем классические балансировщики нагрузки AWS (ELB), AWS сообщает нам, что на ELB нет постоянства сеанса.
Я пытаюсь понять, как файлы cookie работают без сохранения в классических балансировщиках нагрузки.
example.com DNS указывает на ELB. В пуле 2 сервера Server1 и Server2
Мы хотим, чтобы пользователь зашел на свою домашнюю страницу на http://example.com/user/12345/ скажем, на сервере 1, если они еще не вошли в систему, они перенаправляются на страницу sso http://example.com/user/login/sso, автоматически войдите в систему и получите cookie SESS<hexnumber> а затем перенаправили обратно на http://example.com/user/12345/
Нам не разрешено добавлять какие-либо серверы сеансов (redis), что является гарантией того, что они останутся на сервере 1 для обоих перенаправлений.
Насколько мне известно, при каждом обращении к example.com пользователь мог оказаться на сервере 1 или сервере 2.
Мой вопрос:
Если они получают cookie на server1, а затем перенаправляются на server2, как server2 узнает, что cookie уже назначен этому пользователю на server1?
Кажется, я думаю о себе кругами. При работе над этим типом настройки в прошлом с использованием LB без сохранения сеанса мы использовали сервер redis для хранения сеансов, и каждый запрос обращался к серверу redis для получения информации о сеансе.
Файл cookie устанавливается в браузере, а не на сервере. Он ограничен доменом и, необязательно, определенным путем в URL-адресе, поэтому, пока оба сервера доступны из одного домена, cookie будет там.
Если cookie указывает на сеанс, то необходимо, чтобы и server1, и server2 каким-либо образом имели доступ к этому сеансу. Если сеансы не могут быть разделены между серверами, вам необходимо заставить пользователя оставаться на определенном сервере. Этого можно легко добиться с помощью DNS и небольшой магии перезаписи URL:
Используя набор простых (ish) правил перезаписи и файл cookie, пользователь может быть привязан к определенному серверу, гарантируя, что его сеанс сохраняется.
Вот еще некоторые подробности.
DNS:
Правила перезаписи:
Логика перезаписи должна быть определена на самом веб-сервере. Все современные веб-серверы имеют очень функциональные языки перезаписи, которые полностью способны реализовать эту функцию.
Если вы не можете использовать базу данных управления сеансами, такую как Elasticache Redis (Redis для простых сеансов не должен стоить более 15 долларов в месяц), то следующий лучший вариант - включить закрепленные сеансы на ELB;
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
Это заставит пользователей переходить на один и тот же серверный узел на протяжении всего сеанса. «Куки, сгенерированные балансировщиком нагрузки» со сроком жизни 900 секунд, должно быть достаточно, но вы можете настроить это.