gonnalearn.com

The problem: Multiple domains hosted on one server needed access to the user’s session data. In my case, various shopping domains were sharing one (SSL-enabled) domain where the users could place their orders.

The solution I found was surprisingly simple: Since these domains were hosted on the same server and used the same session save path, I was wondering if I could simply pass the existing session ID along to the new domain in order to give it access to the corresponding session file. Indeed all it took was a hidden form field containing the session ID and something like “session_id($_POST['SID'])” on top of the first page of the ssl-domain (before session_start()). Voilà, the old session ID was also the new one and the ssl-domain could continue working with the session data.

On top of that, if the user returned to the previous domain (anywhere!), his – possibly updated – session data was still available there, too (unless he had somehow deleted the session cookie). If I had opted to actually pass the session data between domains and not just the ID, this “seamless” user experience would’ve been harder to achieve.

Now where’s the catch? Well – obviously – once business takes off and several servers become necessary to handle the load, I’ll be cursing myself for not implementing a databased-based* solution for session management like the one mentioned in recipe 11.4. of the PHP Cookbook.

*“Database-based” sounds really bad, no wonder it’s “database-aware” in the book. Can I call it “databased”?

Back to reality, on a managed or shared server there’s always the danger of the admin breaking this simple solution. The obvious candidate for disaster would be the session save path, which has to be the same for all domains (but hopefully different from other client’s paths). A way more obscure modification by my webhost caused some panic this morning: the suhosin.session.cryptdocroot flag was apparently set to “on” and did what it was designed to do, forcing the ssl-domain to start a new session file and thereby overwriting the customers’ shopping carts once they tried to check out.

The problem: Multiple domains hosted on one server needed access to the user's session data. In my case, various shopping domains were sharing one (SSL-enabled) domain where the users could place their orders. The solution I found was surprisingly simple: Since these domains were hosted on the same server and used the same ...