httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cassiel <raffaele.more...@gmail.com>
Subject Re: [users@httpd] Keep session variables alive
Date Sat, 11 Oct 2008 08:28:55 GMT
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 <tevans.uk@googlemail.com>

> 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
>

Mime
View raw message