2

So here's the sitch:

Load balancer (haproxy) delivering to 3 web servers and a database server, 5 servers in total with memcache sessions being shared between the web servers. I can confirm that PHPSESSIONID is being shared between the web servers, however when I try to login, $_POST keeps getting reset and the logged in cookie is never set, resulting in a constant redirect to the login page.

I've set appsessionid in haproxy and that works, but it defeats the purpose of using a load balancer in my mind as most users will be logged in, so its quite probable one server will receive more traffic than others. Has anyone encountered this and any ideas how to solve it? Or am I forced to use sticky sessions?

EDIT 1:

Did some more research and realized I could save $_POST in $_SESSION, but there could be some security concerns. My thought would be to wipe it from session in the shutdown action on every page. Thoughts?

EDIT 2:

Here's /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
  • Please post a sanitized configuration. – Jim G. Nov 24 '14 at 16:01
  • Configuration posted @JimG.! – Nathaniel Schweinberg Nov 24 '14 at 16:17
  • Does the behavior remain if you remove the "option abortonclose" from the defaults section? – Jim G. Nov 24 '14 at 19:05
  • Removed "option abortonclose" and the behavior remains =\ – Nathaniel Schweinberg Nov 24 '14 at 20:15
  • This sounds like a very long standing (and rare) WordPress bug which has been around for several years. I've seen it occasionally but haven't yet been able to track it down. – Michael Hampton Oct 9 '16 at 4:42
0

I know this is an old thread but wonder if there were some 303 redirections on the web server. In that case the client will retry with GET and the POST data will be lost. Use 307 redirect instead.

  • Why is 303 bad and 307 good? – chicks Oct 9 '16 at 13:19
  • 307 preserves the method in the consecutive request from the client (meaning if the initial was POST the next one will be POST too otherwise by default is GET) where is 303 does not. – IgorC Jan 25 '17 at 4:18
0

I use this on sites that return both secure (https) and unsecured (http) data on the same page:

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

I then updated the WP configs for the site from 'http://some_site.com' to 'https://some_site.com'.

This worked as expected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.