Handling PHP sessions between servers

[rycrostud]

Hi,

I'm currently working on a site where the hosting provider I have to use has separate SSL server i.e. the site is on www.mydomain.com but any secure stuff has to be on www.secure.hostingcompany.com/mydomain.com/

So I write a load of login / registration scripts which all work fine EXCEPT when you log in on the secure server and your session cookie is set this is not recognised when you're sent back to the main site, because it's a different domain.

I'm sure this is not an uncommon problem. Any ideas about what the best way to tackle this would be? The solution needs to be simple and more importantly SECURE.

Any help greatly appreciated.

[jatar_k]

To be honest you can't manage the two together. We have both secure and nonsecure sites/sections and we manage the 2 sessions seperately.

Our login page is on the secure server as well as all member section stuff. When they swap over to the public site, which is still accessible through the menu, none of the info in the session is accessible therefore we don't use it.

We maintain a different session on the public site but it is mainly for referrers so it isn't really used except when people sign up.

[lorax]

I apologize in advance for this stupid question but why are you trying to carry/use the session id on the unsecure server? It makes more sense to me to try and keep anything requiring a session id on the secure server.

[rycrostud]

Example...

A summary of the current contents of the shopping cart will be shown on every page. A session is required to identify the user. It's a permanent cart that will stay open for several months or until the customer finally closes the sale, which is why a login is required. The session id needs to be available to every page - but without passing it in the URL.

I'm waiting for a response from the hosting company to see if they can arrange [mydomain.com...] which will solve all my headaches.

[lorax]

Alternately you could move the whole site to the secure server but probably not what you want to do.

[wruk999]

Forgive me if this is blantantly stupid - but can you use a central database for handling the sessions (basket sessions?) then have cookies with an identifier so that the script reads the seesion id in the cookie, which relates to one in the database and can grab the data?

A shopping cart I have uses this type of thing - basket sessions are stored in the database, with a table for BasketItems, which relate to the basket session.

Without going in to too much depth - but just a thought.
Maybe this is how you're doing it and I am just completely missing the plot ;)

Regards,
wruk999

[rycrostud]

lorax - yeah I thought about this but as you say it's probably not something I'd want to do if possible.

wruk999 - I'm starting to think along these lines. I'd probably need to store things like the currently selected language and currency in the DB too. A bit of a pain though when PHP sessions are usually so easy to use.

[lorax]

Another thought. Just because your entire website is on a server with SSL support doesn't mean you have to use it. In other words. Call HTTPS only for those pages that require it. That's how I work with my sites which reside on a server with a shared Cert (which is what you're using right?).

[rycrostud]

lorax - unfortunately in this case you do. The host's secure server is set up so that any requests for pages at [secure.hostingcompany.com...] are refused, it has to be https://

Anyway I'm working on a pretty good workaround at the moment. Thanks for all your input.

[Red_Eye]

I don't know much about session (I am just starting to learn). But could you not write a script that passes the session vairables from the session on the none secure server to a new session on the secure server.

[wruk999]

Red_Eye,

This would be possible like this:

[nonsecuredom.com...]
[securedom.com...]

And then just call via a $HTTP_GET_VARS['id']
These would still need to be centrally stored, and the best way for that is via database.
The other problem is that the session id _could_ be tampered with. Not saying it will - but could be ;)