I don’t know why I didn’t see that the two cookies were named the same. In fact, I don’t need a cookie for the sso backend since it is not load balancing. oops :) Thanx for seeing my over sight. I changed the cookie id and that fixed the problem (makes perfect sense).
Everything is now working perfectly, but since you asked, here is the explanation of what I am trying to accomplish: I have haproxy in front of a set of tomcat servers. These applications look for an authentication token. If the user does not have a valid auth token, redirects them to another server for authentication. Right now, that server is running on the same box that haproxy is running on. I could modify the code so that the redirect does not go through haproxy (takes a little more cert management work — which I typically procrastinate :)). In this case, I took a shortcut and just told haproxy to use a different backend for any url that starts with “/cas” and send those requests over to this other server. That server, then redirects back to the application. The frontend is simply taking requests from stunnel. Port 80 is setup to redirect back through https (stunnel) which then forwards through port 81. I really appreciate your time. Hopefully I can return the favor sometime. LES On Oct 29, 2010, at 12:13 PM, Willy Tarreau wrote: > What I don't understand is that you're having multiple backends > with the same cookie name, and with colliding values. So either > this is deliberate, then I find it strange that cookie value A > is once for a server on port 8080 and once on port 18080. Or it's > not expected at all and in this case what happens is that haproxy > sticks on the cookie value when switching from one farm to the other > one. In this case, you should simply have different cookie names for > each backend. > > Maybe you should start by renaming your SSO cookie "SSO_ID" instead > of "SERVERID". Also, is it on purpose that you have a persistence > cookie and only one server in the SSO backend ? > > Regards, > Willy > > On Fri, Oct 29, 2010 at 11:52:57AM -0400, Les Stroud wrote: >>> My config file is below. By way of explanation, I am using an acl to >>> redirect urls that start with /cas to my single signon server. Everything >>> else goes to my tomcat servers. If I run ab without using a url that goes >>> to /cas, then everything roundrobins fine. However, my applications >>> redirect to /cas which in turn redirects them back to the haproxy cluster >>> once authenticated. When I go through this process, haproxy always puts >>> the session on the first tomcat instance. Is there a way for me to debug >>> how haproxy/my config is making decisions on which backend to use for a new >>> session? >>> >>> Thanx, >>> LES >>> >>> ============= >>> global >>> log 127.0.0.1 local0 info >>> maxconn 25000 >>> stats socket /tmp/haproxy.sock level admin >>> defaults >>> log global >>> clitimeout 60000 >>> srvtimeout 300000 >>> contimeout 4000 >>> retries 3 >>> option redispatch >>> option httpclose >>> option abortonclose >>> >>> listen http_https_redirect *:80 >>> mode http >>> acl stunnel src 192.168.xxx.zzz/32 >>> redirect prefix https://erp.barnhardt.local unless stunnel >>> >>> frontend tomcat *:81 >>> mode http >>> acl ssorequest path_beg /cas >>> use_backend sso if ssorequest >>> default_backend tomcat_cluster >>> >>> backend sso >>> mode http >>> balance roundrobin >>> option forwardfor except 0.0.0.0 >>> reqadd X-Forwarded-Proto:\ https >>> cookie SERVERID insert indirect >>> option httpchk HEAD /check.html HTTP/1.0 >>> server sso 192.168.xxx.zzz:18080 cookie A check >>> >>> backend tomcat_cluster >>> mode http >>> stats uri /haproxy?stats >>> stats enable >>> balance roundrobin >>> option httplog >>> option forwardfor except 0.0.0.0 >>> reqadd X-Forwarded-Proto:\ https >>> cookie SERVERID insert indirect >>> option httpchk HEAD /check.html HTTP/1.0 >>> server tomcat01-instance1 192.168.xxx.xxx:8080 cookie A check port 8081 >>> inter 2000 >>> server tomcat01-instance2 192.168.xxx.xxx:18080 cookie B check port >>> 18081 inter 2000 >>> server tomcat02-instance1 192.168.xxx.yyy:8080 cookie C check port 8081 >>> inter 2000 >>> server tomcat02-instance2 192.168.xxx.yyy:18080 cookie D check port >>> 18081 inter 2000 >>> >>> server bkup-tomcat01-instance1 192.168.xxx.xxx:8080 cookie A check port >>> 8080 inter 2000 backup >>> server bkup-tomcat01-instance2 192.168.xxx.xxx:18080 cookie B check >>> port 18080 inter 2000 backup >>> server bkup-tomcat02-instance1 192192.168.xxx.yyy168.60.157:8080 >>> cookie C check port 8080 inter 2000 backup >>> server bkup-tomcat02-instance2 192.168.xxx.yyy:18080 cookie D check >>> port 18080 inter 2000 backup >>
