Hi,
maybe the answer it obvious, but I couldn’t google it:
I have two different tld domains (domain.com and domain.de) and want to set all cookies usable for both domains.
How do I do this?
Do I just set two cookies?
<?php
setcookie("mycookie", "$value", time(), "/", ".domain.com", 0, true);
setcookie("mycookie", "$value", time(), "/", ".domain.de", 0, true);
?>
But then some people don’t allow setting cookies from other domains as the host’s itself…
Regards
Flözen
Cookies can only be read by the domain that created them.
It will only be a problem if you have people visit the same page using both domains. As long as they only access either one domain or the other they will not need a second cookie.
Well, they would. For some reasons, I sometimes want to send the user from domain.de to domain.com. He still should be recognized correctly. (-> no new login).
Use one TLD, redirect all other TLDs to the one.
No, the .com is the English page, .de the German…
You have to. Browser security does not allow cross domain cookies. Period.
Also when writing?
OK, maybe I have to get a little more specific.
My CMS is in German and English, but I want to strictly separate them by tld.
Some reasons are:
1.) Better tracking of different user groups for different languages.
2.) SEO - for search engines these are two different sites, and the clients come form different locations.)
3.) Easier for ad marketing
So in my case a user, that is for example is already logged in might want to change the language. (Would usually occur for German users, that found the English content first).
So how could I transfer the already set cookie safely from one to the other domain?
Or is there no other way, than a new login?
You could possibly pass a token in the querystring on the end of the URL when going from one domain to the other. That could then be used to establish the same info in a cookie on that domain.
Passing the Cookie in a query string would be like a login with the GET-method. I don’t think this is a good idea…
How does google do it? When you log in at google.com, you are also logged in at all other google tlds…?!
What about putting a 1x1 pixel on the welcome page that sets the same cookie on all the domains you want to use?
It wouldn’t be unsafe as you could only access that page if you have the login credentials.
You mean to call one gif from each domain, where I need to set the cookie?!
<img src=“http://www.domain.de/cookie_image.php” />
<img src=“http://www.domain.com/cookie_image.php” />
Sounds like a good idea!
What’s to stop me loading these resources manually once I know the URL? I would, assumedly, be able to access them without logging in… no?
If not, why(how) not?
That’s a bit of a simplified example. You would need some sort of authentication in there too.
Perhaps set up a table in your database that holds a cookie name and value pair that relates to a randomly generated code.
This code would be generated on login and only valid for one use for each domain. When the appropriate code is accessed, the relevant cooke is set for that domain. Once it has been set once, that authorisation code cannot be reused on that domain.
So you would end up with something like this:
<img src="http://www.domain.de/cookie_image.php?auth=343417982361298735619832465193487568923765" />
<img src="http://www.domain.com/cookie_image.php?auth=343417982361298735619832465193487568923765" />
Would be complicated to set up, sure. But not impossible.
Are we not back where we started then? 
To make it more secure, I could
use a timestamp in the db - so it needs to be used within 5 minutes, afterwards the row can be deleted (to keep table small)
call to the row has to come from same IP as the cookie info was set earlier
A Browser ID match could be used too.
This way someone would have to use the same IP, same browser and do this within 5 minutes… Most unlikely.
Actually, very likely in a corporate environment. 
5000+ of my users all use the same IP and browser to access the internet, and we’re certainly not unique.
You are absolutely right. I was thinking more in terms of hijacking someones account.
The evil person would need to know the exact image url, have the same IP, same Bowser and would have to do so in 5 minutes. This is especially with our costumers most unlikely.
After first download of the image the db file could, or should be deleted anyway.
The unique image ID with a db connection, with short time information, has the benefit, that a spidered image url would have no use.
Finally we are not handling very sensitive information nor money transactions…
The answer to the original question was “no, you can’t”. We are trying to find ways around this.
I don’t even know that you would need to do this.
It depends on what you are using this for. How is somebody going to get access to the secure auth code to set the cookie? They could look at the source of the page, but by then the code would already have been used so it’s useless.
And if they can intercept the code before it has been used then they would probably be able to intercept your username and password anyway (or whatever it is you are trying to protect).
If you can let us know what you are trying to achieve maybe somebody can give you some more specific ideas on what you should do.
I’m not being obstructive, I’m trying to lead the conversation a little. I was concerned the OP was going to implement a poor solution. 
Excellent! Finally. I was hoping the OP would elaborate without prompting though.
If the end result is to merely store a preference (colour scheme, for example), then the implementation could change drastically to say viewing account details.
For me, it’s the fact this security hole/vulnerability exists and is possible - not that it’s hard to do.