melbourne chapter

Updated 15 June 2007: I have provided the source code to this and a working example of sharing a session across unique domains here.

In-light of a recent project I have had to consider a strategy from diverting a user from an non-SSL server running to a different domain running SSL, and keep the same session. This would involve keeping the user who is signed in on the first server with a session cart selection being somehow shared to the next server. It also requires that the user have a single sign-in between several different domains.

Get your sessions into a database
To consider the sharing of information between different domains where they are potentially run by different users or servers, we would need to place the session information directly into a database that is able to be read in by each domain.

To get your sessions into a database, we could:
- Gain control of the Session with a PHP SessionWrapper using a Singleton
- Overwrite the main _open, _read, _write, _close, _destroy and _gc methods to persist to a common datasource (MySQL database)
- Create a _sessionInit method that checks for a PHPSESSID from the Request, if not checks the Cookie for a PHPSESSID
- Create the session with the ID present (if one)

My database table (session) would form:
- sessionkey varchar(32)
- data text
- expiry timestamp

This will securely conform with ownership issues in PHP Safe Mode as the session data will not be written to disk under each web user, it will be written to a common secure database accessible by other websites (with the correct username/password etc). Once again as you will be now taking over some of the security of a session you could read on ways of encrypting the information stored in the database for further security. You will simply need to add methods of encrypting the information (either with Symetrical or Assymetrical keys) in your _read and _write methods of your Session Wrapper.

* Note: I would recommend that you don’t store sensitive information in your session as by default it will be serialised in clear text to your datastore. Anyone capable accessing your session information will be able to see the details (such as CC details etc).

Updated 21 June 2006: Zend provide a good Code Gallery spotlight that gives a good example of a custom session handler to MySQL Database. You can read their article here.

Sharing the Session ID between sites
When diverting the user to the Secure server they would be parsed over using a URL containing the current PHPSESSID to resume on the next hosting service. If they end up at the website without travelling through a URL with PHPSESSID we can attempt to gain it from the user VIA the cookie (if present this is done automatically by PHP). But how can we ensure the user isn’t starting new sessions?

Centralised Issuing Session ID Server
So we have centralised our Sessions and made them available across multiple domains, but how can we further further ensure that the user holds onto the same Session ID? As there is not always clear sever points between the applications, parsing the Session ID in the URL might not be always as easy to track. Even if we searched through all links and applied the PHPSESSID in the URL - a user may decide to type in a domain directly to switch to the different server.

Unfortunately Cookies can not be shared across different domains (* although they can be across subdomains), so we cannot simply keep track of a session ID via a cookie.

A way to backup remedy to this would be to involve a Session ID issuing server that you can bounce a visitor off when creating an initial visit. The user is returned to the site URL they were requesting but after having a centralised Session ID inserted into their request. Also, if for some reason you wish to not reveal the Session ID in the bounce you could simply place in a retrieve_key that looks up the Session ID once the user is returned to their previous URL. You would also need to assign to the session a unique variable that indicated the session was “issued” and is not created by itself.

Using this central session ID manager as a fall back we could help eliminate those cases when the user shows up at a different domain and starting a new session ID. In some cases you may even be able to eliminate the requirement of parsing PHPSESSID in the URLs.

You will need to consider the security implications of handling sessions this way. If you need to regenerate a session ID it must be done with the Centralised Issuing server otherwise you will either loose the information in your session or start dual sessions that are not shared.

In most cases we will try to use the SSL server as the centralised issuing server and all secure steps can be processed under this URL. We can destoy the session on this server and start a new session. It will automatically cause the other domains to try and retrieve a new key (as long as we assign to the session a unique variable that indicated the session was issued, as when the session can’t be resumed on the other domains, they will realise they have to get a new session ID from the centralised server).