4

I have a website running with two subdomains, both of which require login (based on the same DB access credentials). In order to make it easier for users, I wanted to change it so they can navigate both subdomains without having to log in separately: essentially, they log in at one of the subdomains and can then freely navigate between one and the other.

One solution I found at Allow php sessions to carry over to subdomains involves changing the session.cookie_domain variable to so that all subdomains would share the session variables, but something seems to be wrong. I can still login at subdomain1 and navigate it, but as soon as I load a page from subdomain2, subdomain1 instantly loses all its session data and I'm taken back to the login page. This also happens the other way around (logging in from subdomain2 at first). Prior to the change, subdomains could be simultaneously logged in but they wouldn't 'see' each other.

What could be causing this problem to occur?

Community
  • 1
  • 1
Silen
  • 65
  • 5
  • 1
    Have you checked to see (in Firebug or Chrome dev console, etc.) what session cookies are getting set in your browser? Or if your session cookie params explicitly set the cookie domain? – WWW Jul 25 '12 at 15:47
  • 1
    Is your php installation has the suhosin patchset? The default session encryption uses the [document root](http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.cryptdocroot) as encryption key so when you try to access the session file from the second domain it will fail to decrypt. – complex857 Jul 25 '12 at 15:52
  • @Crontab : The cookie being set is the exact same for both subdomains. They share the same value, and their domain is set as "..com". I've noticed that the cookie stays the same even when navigating between subdomains, so the client browser seems to be getting exactly what it should. The problem appears to be that the server is discarding variables for that sessionID whenever I move between subdomains. – Silen Jul 25 '12 at 16:21
  • are they still using the same session ID or is that changing? if it is you might try pass the session ID when the user clicks the link. You can then tell it specifically which stored session to use. – mic Jul 25 '12 at 17:00
  • No, the session ID stays the same for both subdomains. I believe complex857 was right about the problem, as the subdomains have different document roots, so trying to open the current session from a different subdomain might be causing the data to be wiped out. I'm still working on a possible workaround, however. – Silen Jul 25 '12 at 17:23

1 Answers1

8

My suspect is the suhoshin project's session encryption feature, this patchset is included in most debian based systems. It can be configured to encode the session file's content with a key generated from various sources, to protect the session contents from other php scripts running on the same machine (shared hosting) or session hijacking. One of the sources is the docroot (enabled by default) which is usually different on every subdomain.

Check if its installed

A simple phpinfo() will report the extension and it's settings, look for a block named suhosin and below that see if suhosin.session.encrypt and suhosin.session.cryptdocroot is on

Disabling the encryption

Obviously you can edit your php.ini to disable the whole encryption or only the docroot part if you have access to the server.

If you don't, and the server is running apache, try disabling it in the .htaccess file of your php app's root like this:

php_flag "suhosin.session.cryptdocroot" 0

If its working you should see the difference in the phpinfo() output. (Local value column)

If your host doesn't allow a .htaccess file, you can set the same variable in php, but its important to do it before session_start(). Hopefully you have some kind of a front controller to place this in.

ini_set('suhosin.session.cryptdocroot', 0);
phpinfo();

The output of the phpinf should be same as in the .htaccess method, cryptdocroot line with an "Off" local value.

complex857
  • 20,425
  • 6
  • 51
  • 54
  • At first, I tried `ini_set('suhosin.session.cryptdocroot', 0);`, which did not work for me. However, the .htaccess method did the job. Thank you for saving my butt. – Rapti Feb 11 '14 at 13:24