Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 23225 invoked from network); 11 Oct 2008 08:29:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Oct 2008 08:29:40 -0000 Received: (qmail 36965 invoked by uid 500); 11 Oct 2008 08:29:28 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 36944 invoked by uid 500); 11 Oct 2008 08:29:28 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 36933 invoked by uid 99); 11 Oct 2008 08:29:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Oct 2008 01:29:28 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of raffaele.morelli@gmail.com designates 64.233.182.187 as permitted sender) Received: from [64.233.182.187] (HELO nf-out-0910.google.com) (64.233.182.187) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Oct 2008 08:28:20 +0000 Received: by nf-out-0910.google.com with SMTP id 30so444344nfu.24 for ; Sat, 11 Oct 2008 01:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=1/e3VMMp4Bfc66coAvKfkl0Snn5zjoLhkR4HZ4z2FHk=; b=RpnC5PjDGI5IMhQZqLb7G3k/jX6b4zQ72Ap5HKmG1hs2+pfXQRFSgCddJ7EfCezAQI fl/WKR0kDihYo4ktbsJC/2/qxwxXcYsXb54imhHqOJpTT1MvRJA+KL9nKohv0DsImXRO NQJ6EpHK94+QkJ6l4klV0S/q5VzZ7ANk+vqt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=jPN/5eL4Vs0rEBD0GJi6MAQpgr9wzpqkKdi7ufpPBrP23mIHKIpAJ70+z7cNo93pND sZ/ZiHWbn5vRLtCWdz1RNGwfhablrCqI2zdk/13dkxaFdgl3FBekosTz6xn0vikzqzfW MH8MDkE+dlULAuT0RPPc2VFqzH4P+RLPTuLC8= Received: by 10.210.24.7 with SMTP id 7mr1672003ebx.98.1223713735348; Sat, 11 Oct 2008 01:28:55 -0700 (PDT) Received: by 10.210.29.14 with HTTP; Sat, 11 Oct 2008 01:28:55 -0700 (PDT) Message-ID: Date: Sat, 11 Oct 2008 10:28:55 +0200 From: Cassiel To: users@httpd.apache.org In-Reply-To: <1223655040.3262.38.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18427_3221802.1223713735342" References: <48E627FD.7050207@newmediagateway.com> <1223655040.3262.38.camel@localhost> X-Virus-Checked: Checked by ClamAV on apache.org Subject: Re: [users@httpd] Keep session variables alive ------=_Part_18427_3221802.1223713735342 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 > 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 > ------=_Part_18427_3221802.1223713735342 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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

------=_Part_18427_3221802.1223713735342--