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 sub1.example.com and sub2.example.com), then it is > possible as long as the cookie is tied to example.com as opposed to > sub1.example.com or sub2.example.com. > > 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 domain1.com and domain2.com 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 provider. 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 siteC. User then visits siteB, and again, doesn't have a current/valid session id. He is bounced to http://siteC/get_session_id?site=siteB . He does have a session in siteC, so he is bounced back to http://siteB/federation?session=$site_c_sess_id 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). Cheers Tom [1] http://lasso.entrouvert.org/ [2] http://shibboleth.internet2.edu/ [3] http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip [4] http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
Attachment:
signature.asc
Description: This is a digitally signed message part
|