Apache Httpd используется в качестве балансировщика нагрузки между двумя серверами конечных точек. Каждый сервер имеет собственную HTTP-аутентификацию. Цель состоит в том, чтобы аутентификация конечной точки была передана пользователю, пользователь вводил свои учетные данные, а проверка подлинности передавалась обратно на сервер конечной точки.
Когда я настраиваю Apache в качестве обратного прокси, аутентификация проходит без проблем. Когда я перехожу на localhost, мне предлагается ввести учетные данные, я ввожу их, и тогда сайт работает нормально. Вот моя конфигурация обратного прокси:
<VirtualHost *:80>
ProxyPass "/" "http://serv123:27001/"
ProxyPassReverse "/" "http://serv123:27001/"
<Location "/">
SetEnv proxy-chain-auth On
</Location>
</VirtualHost>
Но когда я добавляю балансировку нагрузки, кажется, что proxy-chain-auth настроен неправильно. Когда я ввожу учетные данные, мне сразу же снова предлагается снова, как если бы они были введены неправильно.
<VirtualHost *:80>
ProxyPass "/" "balancer://mycluster/"
ProxyPassReverse "/" "balancer://mycluster/"
<Location "/">
SetEnv proxy-chain-auth On
</Location>
<Proxy "balancer://mycluster">
BalancerMember "http://serv123:27001/"
BalancerMember "http://serv456:27001/"
</Proxy>
</VirtualHost>
Я также пробовал <Location "balancer://mycluster"> и <Location "balancer://mycluster/"> безуспешно. Кто-нибудь знает, как правильно пройти аутентификацию через Apache Httpd с балансировкой нагрузки?
В этой балансирующей конструкции на каждый запрос может (и, скорее всего, будет) ответить другой сервер, поэтому файл cookie браузера, содержащий идентификатор сеанса, перезаписывается при каждой последовательности запроса-входа в систему, и сеанс кажется всегда недействительным.
Есть несколько способов обойти эту проблему:
При использовании stickysessions это вариант, вы можете использовать эту простую систему, чтобы гарантировать, что пользователи всегда обрабатываются одним и тем же сервером (пока он жив и действителен файл cookie). Обратной стороной является то, что когда сервер умирает, пользователь должен снова войти в систему. https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#stickyness
Если о потере сеанса не может быть и речи, вы должны убедиться, что приложения на обоих серверах всегда знают обо всех логинах / сеансах. Таким образом, вы можете использовать серверную часть базы данных (или даже сохранить эту информацию в центральном хранилище в виде файлов), чтобы сохранять их и проверять каждый запрос на соответствие этим db-saved-sessions. Обратной стороной является переключение сервера на каждый второй запрос, что снижает эффективность кеширования на стороне сервера.
объедините обе попытки, чтобы обеспечить эффективное кэширование: последующие запросы всегда обрабатываются одним и тем же сервером (закрепленные сеансы), а когда один сервер выходит из строя, другой берет на себя управление и восстанавливает сеанс из бэкэнда сеанса. На этом этапе кеширование необходимо повторить, если вы не используете общий memcached или аналогичный подход.