[Fixed]-Cookies across subdomains and hosts

12👍

For the benefit of anyone reading this question the code and information contained in the original post are exactly correct and work fine.

The problem is when you introduce other technology. For instance, I have since learned that sending PHP code through a Python module, one that allows Django to serve PHP files/content, changes a great deal about what is accessible to the script and what is not.

This was eventually discovered following the advice of Marc Novakowski, who suggested sending $_COOKIE to the log in order to find out what was there.

I also checked out $_SERVER and $_GET. It was the emptiness of $_GET that tipped me off that the setup I am attempting to use is not as straightforward as I had thought. It was that mistaken understanding that led to not including the information about Django in the original post.

Apologies and thanks to all who responded to this question!

👤nmjk

4👍

Cookies set in domain

'.aaa.sub.domain.com'

will collide with identically named cookies set in domain

'.sub.domain.com'

and '.some.stupidly.obscure.multi.sub.domain.com'

That means (and this took some time to wade thru) if you’re going to use the same-named cookie across multiple domains, you must set it once (and once only) in the main/base domain, in this case ‘.domain.com’; otherwise, the resulting cookie will be indeterminantly and randomly returned arrived at, sometimes the cookie ‘jasper’ set in .a.sub.domain.com, sometimes the cookie ‘jasper’ set in .sub.domain.com, sometimes the cookie ‘jasper’ set in .b.c.d.domain.com, sometimes the cookie ‘jasper’ set in ‘.sub.domain.com’ and sometimes the cookie ‘jasper’ set in ‘.domain.com’

👤FYA

3👍

Does one of the subdomains use an underscore ? IE has problems accepting cookies from subdomain’s that dont follow the URI RFC.

This is asumming ‘distant’ is a placeholder and not the actual subdomain name and of course that you use IE. Although more browsers could very well be effected by as, Fireworks doesn’t though.

1👍

I’d try installing Charles Proxy and see what headers are a) being sent to Firefox to begin with (to set the cookie) and b) which headers are being sent from Firefox to the second server. At least that way you can narrow down where the problem is (browser or server).

-3👍

From php.net about the setCookie-function:

The path on the server in which the cookie will be available on. If set to ‘/’, the cookie will be available within the entire domain . If set to ‘/foo/’, the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain . The default value is the current directory that the cookie is being set in.

The domain that the cookie is available. To make the cookie available on all subdomains of example.com then you’d set it to ‘.example.com’. The . is not required but makes it compatible with more browsers. Setting it to www.example.com will make the cookie only available in the www subdomain. Refer to tail matching in the Β» spec for details.

Basically: Your 4. and 5. parameter needs to be checked: Well, your path seems to be fine, but the domain needs to be changed:

Today you block the cookie to all others than domain A, but you want it to be awailable to both domain A and B. This is a bit tricky, but can be solved. Get inspiration on 15seconds πŸ˜‰

Leave a comment