Hi, On Thu, Sep 01, 2011 at 01:40:22PM +1000, Leigh Dyer wrote: > We allow our users to create their own custom domains, so it's several > thousand domains at the moment. We don't have to worry about subdomains > on those custom domains, though, so I could probably use one backend for > our primary domain plus its subdomains, and a second backend that leaves > the domain on the cookie blank. Would that work?
It's not even certain :-/ I had to run a number of tests about one year ago on cookie domains to see how browsers used to process them. There are about as many behaviours as there are browsers. Some accept to learn a cookie for a domain which is different from the one they visit, some don't. Some are very restrictive and strictly apply the rule from RFC2965 (subdomain matching exactly the full hostname minus the first component), some also accept a full host name in the cookie, some even accept an IP address. Given all the security impacts there are in injecting cookies in browsers, we can only expect a progressive hardening in browser rules, even if this means breaking some existing apps. I invite you to read RFC6265 which replaces 2965 and puts the real issues on the table as they currently are. What you can do however at the haproxy level is to use the cookie prefix mode. The idea is that you'll use the application cookie as a carrier for the stickiness. This means you don't need to worry about those rules in your haproxy configuration, you'll automatically adapt to any tricks that your customers might invent for their apps. If they're able to pass a session cookie between two domains, then haproxy will find it. Regards, Willy
