session across multiple domains

[MasterACE14]

Hello,

 

I have two websites on the same server, but with two different domain names. I have it setup so you have a single account which you can log into either website. So if you're logged into one of the sites, you're automatically logged into the other website as well. This all works fine locally as it's the single domain http://localhost/ however on my website when you log into one, you have to then log into the other one as well because obviously the session saves to the one domain.

 

After googling I found.... session_set_cookie_params(0, '/', '.crikeygames.com.au'); works fine for that domain and all subdomains, but I believe I can only use this function once? or atleast for only one domain.

 

I have seen people saying you can append the session id to the URL when switching between the sites to maintain the session. I'm not sure if that's the most ideal way.

 

Maybe it can be achieved with .htaccess? Or would session_set_save_handler() be the way to go?

 

Thanks,

Ace

[PFMaBiSmAd]

You will have two problems -

 

1) If your server is set up correctly (securely) and using the default/common tmp folder for the session data files, the ownership/permissions of the session data files won't permit the files created under one domain/account to be accessed by the other domain/account. Also, if you are already using 'private' folders under each domain/account for the session data files, you would not be able to access the session data files created under one domain/account from the opposite domain/account.

 

2) The browser (using cookies for session id) or php (using the transparent sid (Session ID) management on the end of the URL for the session id) won't propagate the session id between different domains. Cookies are domain specific (due to the built-in security for cookies) and php simply won't due to the security implications -

Non-relative URLs are assumed to point to external sites and hence don't append the SID, as it would be a security risk to leak the SID to a different server.

 

To solve #1, you must store the session data using a means that permits access by both domains/accounts. Using a database based custom session save handler would solve this problem.

 

For #2, since you cannot change how browsers propagate cookies between domains and you probably don't want to rewrite part of php to get the automatic sid management to operate differently, you would need to rewrite the scripts on both of your sites to build any links that move between the two domains with the session id on the end of the URL, then hope that someone doesn't manually type a URL (without their current sid) or have a shortcut/bookmark saved (with no sid or an old sid) to go between the two domains as that would loose the session id and their login would not transfer to the different domain.

 

Why exactly do you want to do this, since common actions by users (having a shortcut/bookmark saved or typing the URL) will cause it to fail?

 

Hmmm. In typing this, I just thought of something you might try (still requires rewriting part of your login code and then making sure that a hacker cannot exploit it.) When someone logs in and gets a sid (or you ever regenerate a sid), you would need to store the sid in the user's row in your user table and then momentarily redirect them to a (blank) page in the opposite domain with that sid on the end of the URL. The page you redirect to would take that sid from the URL, find the matching row in the user table (to identify the user/get his userid), and then start a session using that sid so that you set a session id cookie under that domain with that sid. You would set any session variables needed to satisfy you login script, the same as if they had just manually logged in under the opposite domain. You would then redirect back to the starting domain. I think that by making sure that the sid stored in the database is unique and then matching the sid passed on the end of the url with one in the database table, that this is as secure as manually logging in on the opposite domain. Perhaps add a timestamp check to the user table as well - if the redirect/sid check in the opposite domain doesn't occur within a short time of when the sid was assigned and stored in the user table, then don't setup the session/automatically log them in on the opposite domain.

[MasterACE14]

To solve #1, you must store the session data using a means that permits access by both domains/accounts. Using a database based custom session save handler would solve this problem.

I'm thinking this may be the best way to go about it.

 

Hmmm. In typing this, I just thought of something you might try (still requires rewriting part of your login code and then making sure that a hacker cannot exploit it.) When someone logs in and gets a sid (or you ever regenerate a sid), you would need to store the sid in the user's row in your user table and then momentarily redirect them to a (blank) page in the opposite domain with that sid on the end of the URL. The page you redirect to would take that sid from the URL, find the matching row in the user table (to identify the user/get his userid), and then start a session using that sid so that you set a session id cookie under that domain with that sid. You would set any session variables needed to satisfy you login script, the same as if they had just manually logged in under the opposite domain. You would then redirect back to the starting domain. I think that by making sure that the sid stored in the database is unique and then matching the sid passed on the end of the url with one in the database table, that this is as secure as manually logging in on the opposite domain. Perhaps add a timestamp check to the user table as well - if the redirect/sid check in the opposite domain doesn't occur within a short time of when the sid was assigned and stored in the user table, then don't setup the session/automatically log them in on the opposite domain.

I can see how that'd work and is a good solution, however I will be adding more websites overtime, so redirecting to 3 or more 'blank' pages to setup a session probably won't be the best approach. For just the 2 domains that's a clever approach.

 

Thanks for your wisdom and knowledge as always!

 

Kind Regards,

Ace