WordPress por trás do haproxy: $ _POST sendo redefinido

2

Então aqui está o sitch:

Balanceador de carga (haproxy) fornecendo para 3 servidores da Web e um servidor de banco de dados, 5 servidores no total, com sessões de memcache sendo compartilhadas entre os servidores da web. Posso confirmar que PHPSESSIONID está sendo compartilhado entre os servidores da web, mas quando tento efetuar login, $_POST continua sendo redefinido e o cookie conectado nunca é definido, resultando em um redirecionamento constante para a página de login.

Eu configurei appsessionid no haproxy e isso funciona, mas ele vence o propósito de usar um balanceador de carga em minha mente, já que a maioria dos usuários fará login, portanto, um servidor provavelmente receberá mais tráfego do que outros. Alguém já encontrou isso e alguma idéia de como resolvê-lo? Ou eu sou forçado a usar sessões pegajosas?

EDIT 1:

Fiz mais pesquisas e percebi que podia salvar $_POST em $_SESSION , mas poderia haver algumas preocupações de segurança. Meu pensamento seria limpá-lo da sessão na ação de desligamento em todas as páginas. Pensamentos?

EDIT 2:

Aqui está o /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
    
por Nathaniel Schweinberg 24.11.2014 / 16:47

1 resposta

0

Eu sei que este é um thread antigo, mas pergunto-me se houve algum redirecionamento 303 no servidor web. Nesse caso, o cliente tentará novamente com GET e os dados do POST serão perdidos. Use o redirecionamento 307 no lugar.

    
por 09.10.2016 / 04:23