Sessions on multiple domains

[eluser]aka_kalle[/eluser]
Hi!
I'm creating a webpage that will be available in 4 languages, each with it's own domain name. How ever the codebase is the same and its all on the same server, the only thing is that the languages is changed depending on the url.

Now my problem is:
When an admin login on one of the pages to edit texts in Swedish, how do I keep him logged in when he wants to edit the english texts and then changing domain?

Is it possible to create a session / cookie that will work for att 4 domains since its all on the same IP / Database? Or maybe create 4 sessions on each login, one for each domain?

Thank you for your input!

[eluser]Phil Sturgeon[/eluser]
You can't create a cookie that works cross-domain, or I'd be logging into your Facebook as we speak.

What you can do is create a unique generic key that contains nothing identifiable, then store that in the database and in a cookie when the user logs in. Next to the unique key in the database store the users ID and IP address too.

Then create a hook that runs pre_controller (or somewhere early) that checks for this cookie. If there is no cookie set, check the database for their IP address (within a small time period to stop IP switching ISP's logging people into random accounts a week later) and if it exists simply re-create the cookie on this site.

If they do not already have a logged in entry, redirect them to the login page or just carry on as is. When they log in it will create on the new site.

OR

use sub-domains. They you can share cookies ;-)

[eluser]flaky[/eluser]
cookies work only inside a domain (and its subdomains), so you can't access cookies for another domain.

[eluser]aka_kalle[/eluser]
[quote author="Phil Sturgeon" date="1262116216"]You can't create a cookie that works cross-domain, or I'd be logging into your Facebook as we speak.

What you can do is create a unique generic key that contains nothing identifiable, then store that in the database and in a cookie when the user logs in. Next to the unique key in the database store the users ID and IP address too.

Then create a hook that runs pre_controller (or somewhere early) that checks for this cookie. If there is no cookie set, check the database for their IP address (within a small time period to stop IP switching ISP's logging people into random accounts a week later) and if it exists simply re-create the cookie on this site.

If they do not already have a logged in entry, redirect them to the login page or just carry on as is. When they log in it will create on the new site.

OR

use sub-domains. They you can share cookies ;-)[/quote]

Excelent idea, thank you! I will consider subdomains aswell thought

[eluser]shaffick[/eluser]
Worked for me for multiple subdomains.

You can set a cookie with the path set as / and domain set as .domainname (the . is very important)

Code:

setcookie($name, $value, $expire, "/", ".domainname.com")

[eluser]Ben Bowler[/eluser]
@phil Sturgeon

I'm trying to do exactly what you're describing with two sights running on CodeIgniter.

Is there any example code out there or longer article explaining the best practices of what you're talking about. I understand what you've said here but I if I leave anything out I'm potentially opening up my site to a big security hole.

[eluser]Phil Sturgeon[/eluser]
1. Make something unique that identifies a user.

2. Pass that unique code around somewhere people wont see it or guess it.

Or, use OAuth.

[eluser]Unknown[/eluser]
I found this mentioned elsewhere... "many OAuth implementation (Twitter, Facebook, Google, Yahoo!) usually use iframes to associate a user on their domain with a successful authentication URL (for after the user logs in)." [found this info on http://stackoverflow.com/questions/37971...se-iframes]

From this I gather that you can use an IFRAME that requests a response from a domain that has the session authentication. The cookies used would necessarily be associated with the domain called. Then javascript could be used to capture the status/verification from the IFRAME. Right?

Or, if you have full control over the domain that has the session authentication, and you are willing to let that server handle everything (returning all content, as mentioned by Summer Student), then your other domains can simply be a full screen IFRAME that calls to the main app, passing a parameter or subdomain that identifies it [see http://www.w3lessons.com/2011/12/create-...-full.html]. In that last case, the visible URL would not be changing if you navigate around the content inside IFRAME... http://example.com/controller-class/cont.../arguments, but visitors could hover over links, or still open the links in a new window or tab and see the full URL.

Just a thought. I have NOT tried these. But I might soon... Making http://slavedomain.com IFRAME to http://slavesubdomain.masterdomain.com... I can use PHP to easily determine what subdomain I am using and adjust code accordingly. Also, I could anchor all links to target="_top" with the full http://slavedomain.com url and they would redirect to http://slavedomain.com/class/method/arguments with an IFRAME to http://slavesubdomain.masterdomain.com/c.../arguments... A links would have to be coded to link back to the http://slavedomain.com/...

[I had to remove the URL blocks because it was not allowing me to post.]