views:

683

answers:

3

Scenario: There will be web application hosted over multiple domains (e.g. www.example.com, www.example.co.uk, www.example-3.com etc). When a user registered over any one of these domains, the data will be stored in centralized master database. When user signin to any one of the website, the session data will be stored in the centralized master database.

Requirement: A logged in user will be able to browse any domain (sharing same session database). And while he/she browses any domain, apart from the domain where he/she actually logged in, the session should remain same, that is no need to login again. We do not want to use any thing like openid.

Question: How can we achieve this requirement based upon the scenario so that we will not need to have any third party service (OpenID, Lasso and a like)?

A: 

That is very good question, try these links out for a possible solution or an idea:

How To Handle Multiple Domains

php keep session active across multiple websites

On the latter site, you will have to register to see the solution. And ofcourse, you will have to modify the session stuff in terms of Zend framework.

Sarfraz
A: 

The problem you're going to have is that there are methods to handle this for different subdomains, but not entirely different domains. Sure you could get the backend of all the sites to have access to the sessions but the problem client side is that you won't be able to share the cookie data (which effectively identifies your session on the server side) between different domains.

The workaround method would involve something like manually passing the session id from the cookie in the querystring between sites which introduces a slight security problem.

This method is described breifly here: http://stackoverflow.com/questions/511541/sharing-session-across-domain/511651#511651

Mailslut
Thanks, I hope this answer will help people.
r0ash
+3  A: 

I'm not convinced what you want is actually possible. Or indeed safe, since as Mailslut suggested you'll probably have to pass the session id in the URL - something highly recommended against since the same technique you'll be using to keep state across domains will leave you open to someone using it for nefarious purposes - and you won't be able to tell the difference.

I think you're better off pushing back against this requirement and accepting that it's not realistic - multiple logins really aren't that bad, as long as you're sharing the same user database across sites. If it keeps user data safe, that's worth the trade-off in my opinion.

You couldn't even do this with cookies, since you'll only receive a cookie for the domain you're currently on - the browser has no way to know if the sites are related.

Stephen Orr
Then what MSN/Hotmail are using? How does passport.com based authentication does not require login to the website of their network?
r0ash
They have a much bigger infrastructure than you're ever likely to have - and also, fewer restrictions on architecture. Passport.com authentication works on a similar level to OpenID (technical differences aside, they both perform the same function), but you've already discounted that as a possibility. Simply put, without an OpenID-style system, you aren't going to accomplish this in a way that is safe for the user.
Stephen Orr
Thanks Stephen.
r0ash

related questions