thank you justin and tom, I solved putting the websites under the same domain and adjusting the php code.
regards r 2008/10/10 Tom Evans <[EMAIL PROTECTED]> > 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 >
