☰

WordPress detrás de haproxy: $_POST siendo reiniciado

tag-icon • tag-icon load-balancing redirect wordpress haproxy login
WordPress detrás de haproxy: $_POST siendo reiniciado

Así que aquí está la situación:

Equilibrador de carga (haproxy) que se entrega a 3 servidores web y un servidor de base de datos, 5 servidores en total con sesiones de Memcache compartidas entre los servidores web. Puedo confirmar que PHPSESSIONIDse está compartiendo entre los servidores web; sin embargo, cuando intento iniciar sesión, $_POSTse sigue restableciendo y la cookie de inicio de sesión nunca se establece, lo que resulta en una redirección constante a la página de inicio de sesión.

He configurado appsessionidhaproxy y eso funciona, pero en mi opinión anula el propósito de usar un equilibrador de carga, ya que la mayoría de los usuarios iniciarán sesión, por lo que es muy probable que un servidor reciba más tráfico que otros. ¿Alguien ha encontrado esto y alguna idea de cómo resolverlo? ¿O me veo obligado a utilizar sesiones fijas?

EDITAR 1:

Investigué un poco más y me di cuenta de que podía ahorrar $_POSTen $_SESSION, pero podría haber algunos problemas de seguridad. Mi idea sería borrarlo de la sesión en la acción de cierre de cada página. ¿Pensamientos?

EDITAR 2:

Aquí está/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

Respuesta1

Sé que este es un hilo antiguo, pero me pregunto si hubo algunas redirecciones 303 en el servidor web. En ese caso, el cliente volverá a intentar con GET y se perderán los datos POST. Utilice la redirección 307 en su lugar.

Respuesta2

Lo uso en sitios que devuelven datos seguros (https) y no seguros (http) en la misma página:

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

Luego actualicé las configuraciones de WP para el sitio desde 'http://algun_sitio.com' a 'https://algun_sitio.com'.

Esto funcionó como se esperaba.

información relacionada