httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Evans <>
Subject Re: [users@httpd] Keep session variables alive
Date Fri, 10 Oct 2008 16:10:40 GMT
On Fri, 2008-10-03 at 09:11 -0500, Justin Pasher wrote:
> Cassiel wrote:
> > Hi you all,
> >
> > I would like to keep session variables alive, between two PHP coded 
> > website, currently two virtual hosts.
> > This is in order to let users login from the main one and then switch 
> > between the twos without loosing $_SESSION info.
> >
> > Any suggestion is appreciated.
> >
> > regards
> > raffaele
> A session variable is simply a cookie in the user's browser that holds 
> their session ID (unless you happen to be keeping tracking of the 
> session ID through the URL, which is a bigger security risk). You won't 
> be able to make it work across two different domain names, as this would 
> be a security hole. If the two virtualhosts share the same top level 
> domain (such as and, then it is 
> possible as long as the cookie is tied to as opposed to 
> or
> Otherwise, you'll have to maintain the "link" between the two sites 
> yourself, such as passing some sort of hash information from one site to 
> the other that tells the site the user's login information. Keep in mind 
> this is not the most secure way of doing things, but you just have to 
> remember that the browse will think and are 
> completely different web site, even if they are the "same" logically.

All of Justin's advice is good, but you can do a very simple 'SSO'
without sharing domains. I'll describe a 3 site system, 2 service
providers, one identity provider, but this can be expanded to cover any
number of sites that have a shared backend resource, like sessions or a
database. The identity provider could even be one of the service

User visits siteA, and doesnt have a current/valid session id. 
He is bounced to http://siteC/get_session_id?site=siteA . 
He doesn't have a session in siteC, so one is created, and he is bounced
back to http://siteA/federation?session=$site_c_sess_id .
siteA has then received a session id that is shared between siteA and
User then visits siteB, and again, doesn't have a current/valid session
He is bounced to http://siteC/get_session_id?site=siteB .
He does have a session in siteC, so he is bounced back to
siteB has then received a session id that is shared between siteA, siteB
and siteC.

This is very weak SSO, check out lasso[1], shibboleth[2] and the SAML
2.0 specs and docs[3] (especially the tech overview[4] is good for an
insight into how proper SSO federations are managed).




View raw message