Btw., to fully understand the problem, this piece of information was crucial:
If multiple cookies of the same name match a given request URI, one is chosen by the browser. The more specific the path, the higher the precedence. However precedence based on other attributes, including the domain, is unspecified, and may vary between browsers. This means that if you have set cookies of the same name against “.example.org” and “www.example.org”, you can’t be sure which one will be sent back. [1]
That also explains the different behaviour between browsers, we found the most login problems with Chrome. It would have been nice if browsers would give priority to the cookie with the closest domain match, but only Safari does that.
Loek [1] http://www.sitepoint.com/3-things-about-cookies-you-may-not-know/ On 05-03-16 00:13, Loek Hilgersom wrote:
Hi Jigal and others, I finally got around digging into this and found the solution is NOT the cookieDomain setting. The essential goal is that the BE and FE login sessions can be shared across the subdomains. Setting the cookieDomain like /\.(sub1|sub2|sub3)\.domain\.com$/ allows cookies to be set for the matching domains, but does not allow the cookie to be shared across the subdomains, because the browser will not allow cookies for one subdomain to be seen by another. The solution I found is modifying the [BE] and [FE][cookieName] settings for the test and acceptation environments. Problem solved! The cookieDomain stays set to .domain.com, (and .test.domain.com / .acceptation.domain.com for the other environments, though they would also work with .domain.com) Hope this helps anyone. Loek
_______________________________________________ TYPO3-english mailing list TYPO3-english@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
