☰

WordPress hinter Haproxy: $_POST wird zurückgesetzt

tag-icon • tag-icon load-balancing redirect wordpress haproxy login
WordPress hinter Haproxy: $_POST wird zurückgesetzt

So ist die Lage:

Load Balancer (Haproxy) liefert an 3 Webserver und einen Datenbankserver, insgesamt 5 Server, wobei Memcache-Sitzungen zwischen den Webservern geteilt werden. Ich kann bestätigen, dass dies PHPSESSIONIDzwischen den Webservern geteilt wird, aber wenn ich versuche, mich anzumelden, $_POSTwird es immer wieder zurückgesetzt und das angemeldete Cookie wird nie gesetzt, was zu einer ständigen Weiterleitung auf die Anmeldeseite führt.

Ich habe appsessionidHaproxy eingerichtet und das funktioniert, aber meiner Meinung nach macht es den Zweck der Verwendung eines Lastenausgleichs zunichte, da die meisten Benutzer angemeldet sein werden und es daher sehr wahrscheinlich ist, dass ein Server mehr Verkehr erhält als andere. Ist das schon mal jemandem passiert und hat jemand eine Idee, wie man es lösen kann? Oder bin ich gezwungen, Sticky Sessions zu verwenden?

BEARBEITEN 1:

Habe noch ein bisschen nachgeforscht und festgestellt, dass ich $_POSTin speichern könnte $_SESSION, aber es könnte Sicherheitsbedenken geben. Mein Gedanke wäre, es beim Herunterfahren jeder Seite aus der Sitzung zu löschen. Was meint ihr?

BEARBEITEN 2:

Hier ist/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

Antwort1

Ich weiß, dass dies ein alter Thread ist, frage mich aber, ob es auf dem Webserver 303-Umleitungen gab. In diesem Fall versucht der Client es erneut mit GET und die POST-Daten gehen verloren. Verwenden Sie stattdessen eine 307-Umleitung.

Antwort2

Ich verwende dies auf Websites, die sowohl sichere (https) als auch ungesicherte (http) Daten auf derselben Seite zurückgeben:

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

Ich habe dann die WP-Konfigurationen für die Site von 'http://irgendeine_site.com' Zu 'https://some_site.com'.

Dies hat wie erwartet funktioniert.

verwandte Informationen