Таким образом, вот sitch:
Подсистема балансировки нагрузки (haproxy) поставляющий к 3 веб-серверам и серверу базы данных, 5 серверам всего с сессиями кэш-памяти, совместно используемыми веб-серверами. Я могу подтвердить это PHPSESSIONID
совместно используется веб-серверами, однако когда я пытаюсь войти в систему, $_POST
продолжает сбрасываться, и зарегистрированный cookie никогда не устанавливается, приводя к постоянному перенаправлению к странице входа в систему.
Я установил appsessionid
в haproxy и это работает, но он побеждает цель использовать подсистему балансировки нагрузки в моем уме, поскольку большинство пользователей будет зарегистрировано, таким образом, его довольно вероятное один сервер получит больше трафика, чем другие. Кто-либо встретился с этим и какими-либо идеями, как решить его? Или я вынужден использовать липкие сессии?
Провел еще некоторое исследование и понял, что я мог сохранить $_POST
в $_SESSION
, но могли быть некоторые проблемы безопасности. Моя мысль состояла бы в том, чтобы вытереть его с сессии в действии завершения работы на каждой странице. Мысли?
Вот /etc/haproxy/haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
daemon
user haproxy
group haproxy
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL).
tune.ssl.default-dh-param 2048
ssl-default-bind-ciphers LONG LIST OF CIPHERS
defaults
log global
balance leastconn
mode http
option httplog
option dontlognull
option redispatch
option http-server-close
option forwardfor
option abortonclose
maxconn 3000
retries 3
timeout queue 1m
timeout connect 10s
timeout client 5m
timeout server 5m
timeout http-request 5s
timeout http-keep-alive 10s
timeout check 10s
frontend www-http
bind xxx.xxx.xxx.xxx:80
reqadd X-Forwarded-Proto:\ http
redirect scheme https if !{ ssl_fc }
default_backend wordpress-backend
frontend www-https
bind xxx.xxx.xxx.xxx:443 ssl no-sslv3 crt /etc/ssl/private/default.pem crt /etc/ssl/private/
rspadd Strict-Transport-Security:\ max-age=15768000
reqadd X-Forwarded-Proto:\ https
default_backend wordpress-backend
backend wordpress-backend
option httpchk HEAD /haphealth
server wordpress-1 xxx.xxx.xxx.xxx:8081 maxconn 10 check
server wordpress-2 xxx.xxx.xxx.xxx:8081 maxconn 10 check
server wordpress-3 xxx.xxx.xxx.xxx:8081 maxconn 10 check
Я знаю, что это старый поток, но мне интересно, было ли на веб-сервере 303 перенаправления. В этом случае клиент повторит попытку с помощью GET, и данные POST будут потеряны. Вместо этого используйте переадресацию 307.
Я использую это на сайтах, которые возвращают как защищенные (https), так и незащищенные (http) данные на одной и той же странице:
frontend WordPress
mode http
option httplog
bind <ip_address>:80 transparent
bind <ip_address>:443 transparent ssl crt <path_to_cert>
http-request set-header X-Forwarded-Proto https # <------ This is the line makes sure everything that's requested is HTTPS
redirect scheme https code 307 if !{ ssl_fc }
default_backend wp_backend
Затем я обновил конфигурации WP для сайта с 'http://some_site.com. » на «https://some_site.com».
Это сработало, как и ожидалось.