Session handling, login across all subdomains

[Josh]

I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.

Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?

Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.

I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.

Any ideas?

[Chetan]

Josh <jj*******@gmail.comwrites:

I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.

Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?

Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.

I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.

Any ideas?

Besides the name of the session cookie and the place where the session
information is stored, both the sites also need to share the idea of who a
"user" is. That would generally mean that both the sites use the same database,
or at least the users information comes from the same table.

That might be question of setup or installing additional modules etc. I don't
know specifics of Joomla.

Chetan

[Jerry Stuckle]

Josh wrote:

I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.

Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?

Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.

I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.

Any ideas?

Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
And even though they are subdomains of the same domain, they are
different sites.

To get them to work with all of your subdomains, in your php.ini file set

session.cookie_domain = .example.com

where example.com is your main domain. The leading period is important.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[C. (http://symcbean.blogspot.com/)]

On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:

Josh wrote:

I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.

Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?

Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.

I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.

Any ideas?

Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
And even though they are subdomains of the same domain, they are
different sites.

To get them to work with all of your subdomains, in your php.ini file set

session.cookie_domain = .example.com

where example.com is your main domain. The leading period is important.

....but test it first - particularly with MSIE 8 and FF3.

A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.

C.

[Jerry Stuckle]

C. (http://symcbean.blogspot.com/) wrote:

On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:

>Josh wrote:

>>I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.
Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?
Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.
I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.
Any ideas?

Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
And even though they are subdomains of the same domain, they are
different sites.

To get them to work with all of your subdomains, in your php.ini file set

session.cookie_domain = .example.com

where example.com is your main domain. The leading period is important.

...but test it first - particularly with MSIE 8 and FF3.

A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.

C.

Cookie handling is defined by the HTTP specs. And this is correct
operation for cookies. Any browser which doesn't accept this is
non-compliant.

But please - give details on how he should implement a single sign on or
rebind the session at runtime.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[C. (http://symcbean.blogspot.com/)]

On Jul 27, 3:59 pm, Jerry Stuckle <[e-mail]:

C. (http://symcbean.blogspot.com/) wrote:

On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:

Josh wrote:
I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.
Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?
Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.
I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.
Any ideas?
Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
And even though they are subdomains of the same domain, they are
different sites.

To get them to work with all of your subdomains, in your php.ini file set

session.cookie_domain = .example.com

where example.com is your main domain. The leading period is important.

...but test it first - particularly with MSIE 8 and FF3.

A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.

C.

Cookie handling is defined by the HTTP specs. And this is correct
operation for cookies. Any browser which doesn't accept this is
non-compliant.

But please - give details on how he should implement a single sign on or
rebind the session at runtime.

Single-sign-on:

if not authenticated at the current vhost redirect to the URL (and
hence vhost) where you do authentication, including a return URL as a
param. At authentication page, if the user presents a valid session
cookie (NB doesn't have to be PHP session cookie, indeed, it'd be
better if it didn't) then redirect back to the return URL including a
token in the params. If no valid session cookie, get them to login and
if valid, redirect back to the return URL with a token as a param.

current.example.com:

if (!authenticated($_COOKIE['auth'])) {
if ($_GET['visa']) {
$decrypt=decrypt($_GET['visa']);
list($auth,$sent)=explode('|',$decrypt);
if (authenticated($auth) && (5<abs($time()-$sent)) {
set_cookie('auth',$auth);
}
}
}
sso.example.com

if (authenticated($_COOKIE['sso_auth'])) {
$visa=encrypt($_COOKIE['sso_auth'],time());
$return=$_GET['return_url'] . '?visa=' . $visa;
header("Location: $visa");
} else if ($auth=check_credentials($_POST['username'],
$_POST['password'])) {
// NB deliberate assignment
$visa=encrypt($auth);
$return=$_GET['return_url'] . '?visa=' . $visa;
set_cookie('sso_auth',$auth);
header("Location: $visa");
} else {
print "<form action='" . $_SERVER['PHP_SELF'] . "' method='POST'>
name: <input type = 'text' name='username'Password: <input tyoe =
'password' name='password'>
</form>\n";
}

Here using a 5 second timeout to reduce the window for replay attacks.

Session rebinding:
If you know that a user has a session id 'ABC' on host 1, and this
shares PHP session storage mechanism with host 2, then you can force
the PHP session on host 2 to use the same session id, and thus the
same session data. This also means that the user will stay logged in
on host 1 even if they don't touch any of its URLs for longer than
than the PHP session's TTL (provided they are still interacting with
host 2), e.g.

on host 1:

require_once('some_encryption_lib.inc.php');
....
session_start();
....
$_SESSION['exported']=true;
print "<a href='http://host2.example.com/?force_session=";
print encrypt(session_id() . '|' . $_SERVER['REMOTE_HOST'] . '|' .
time()) . "'>Go to other site</a>";

on host 2

require_once('some_encryption_lib.inc.php');
....
if ($_GET['force_session']) {
$decrypt=decrypt($_GET['force_session']);
list($remote_session,$host,$sent)=explode('|',$dec rypt);
if (($host==$_SERVER['REMOTE_HOST']) && (abs(time()-$sent)<300)) {
session_id($remote_session);
} else {
// ?
}
}
sesion_start();
if (!$_SESSION['exported']) {
// session referenced is dead - reinitialize and/or re-authenticate
}

Here I'm using the client IP and the time the link was generated to
prevent CSRF - this won't work for AOL customers, nor if the link is a
accessed more than 5 minutes after it has been generated.

C.

[Jerry Stuckle]

C. (http://symcbean.blogspot.com/) wrote:

On Jul 27, 3:59 pm, Jerry Stuckle <[e-mail]:

>C. (http://symcbean.blogspot.com/) wrote:

>>On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:
Josh wrote:
I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.
Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?
Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.
I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.
Any ideas?
Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
And even though they are subdomains of the same domain, they are
different sites.
To get them to work with all of your subdomains, in your php.ini file set
session.cookie_domain = .example.com
where example.com is your main domain. The leading period is important.
...but test it first - particularly with MSIE 8 and FF3.
A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.
C.

Cookie handling is defined by the HTTP specs. And this is correct
operation for cookies. Any browser which doesn't accept this is
non-compliant.

But please - give details on how he should implement a single sign on or
rebind the session at runtime.

Single-sign-on:

if not authenticated at the current vhost redirect to the URL (and
hence vhost) where you do authentication, including a return URL as a
param. At authentication page, if the user presents a valid session
cookie (NB doesn't have to be PHP session cookie, indeed, it'd be
better if it didn't) then redirect back to the return URL including a
token in the params. If no valid session cookie, get them to login and
if valid, redirect back to the return URL with a token as a param.

current.example.com:

if (!authenticated($_COOKIE['auth'])) {
if ($_GET['visa']) {
$decrypt=decrypt($_GET['visa']);
list($auth,$sent)=explode('|',$decrypt);
if (authenticated($auth) && (5<abs($time()-$sent)) {
set_cookie('auth',$auth);
}
}
}
sso.example.com

if (authenticated($_COOKIE['sso_auth'])) {
$visa=encrypt($_COOKIE['sso_auth'],time());
$return=$_GET['return_url'] . '?visa=' . $visa;
header("Location: $visa");
} else if ($auth=check_credentials($_POST['username'],
$_POST['password'])) {
// NB deliberate assignment
$visa=encrypt($auth);
$return=$_GET['return_url'] . '?visa=' . $visa;
set_cookie('sso_auth',$auth);
header("Location: $visa");
} else {
print "<form action='" . $_SERVER['PHP_SELF'] . "' method='POST'>
name: <input type = 'text' name='username'Password: <input tyoe =
'password' name='password'>
</form>\n";
}

Here using a 5 second timeout to reduce the window for replay attacks.

Session rebinding:
If you know that a user has a session id 'ABC' on host 1, and this
shares PHP session storage mechanism with host 2, then you can force
the PHP session on host 2 to use the same session id, and thus the
same session data. This also means that the user will stay logged in
on host 1 even if they don't touch any of its URLs for longer than
than the PHP session's TTL (provided they are still interacting with
host 2), e.g.

on host 1:

require_once('some_encryption_lib.inc.php');
...
session_start();
...
$_SESSION['exported']=true;
print "<a href='http://host2.example.com/?force_session=";
print encrypt(session_id() . '|' . $_SERVER['REMOTE_HOST'] . '|' .
time()) . "'>Go to other site</a>";

on host 2

require_once('some_encryption_lib.inc.php');
...
if ($_GET['force_session']) {
$decrypt=decrypt($_GET['force_session']);
list($remote_session,$host,$sent)=explode('|',$dec rypt);
if (($host==$_SERVER['REMOTE_HOST']) && (abs(time()-$sent)<300)) {
session_id($remote_session);
} else {
// ?
}
}
sesion_start();
if (!$_SESSION['exported']) {
// session referenced is dead - reinitialize and/or re-authenticate
}

Here I'm using the client IP and the time the link was generated to
prevent CSRF - this won't work for AOL customers, nor if the link is a
accessed more than 5 minutes after it has been generated.

C.

And exactly how dows this help with multiple subdomains? The cookies
(including the session id cookie) aren't passed to different subdomains
unless he makes the change I suggested. So there is no way to tell from
one subdomain to another whether the user is logged in or not.

And if he makes the change I suggested, he doesn't need all this extra
stuff.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Richard Levasseur]

On Jul 29, 10:52*am, Jerry Stuckle <[e-mail]:

C. (http://symcbean.blogspot.com/) wrote:

On Jul 27, 3:59 pm, Jerry Stuckle <[e-mail]:

C. (http://symcbean.blogspot.com/) wrote:
On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:
Josh wrote:
I run a Joomla website and am familiar with php in some but not all
aspects. Currently I am trying to find some solutions related to
session handling.
Am I correct in saying that "login" is kept in sessions? I can see
active sessions in my mysql database, but is that the only place this
information is stored? Sessions and cookies I know are related also,
but how specifically (session info stored in cookies?)?
Right now, when users login at example.com, and then visit
subdomain.example.com, they are not logged in at the subdomain. I am
trying to change this so that users logged in on the main site or any
subdomain are also logged in across all other subdomains and the main
site. I know sites like livejournal successfully accomplish this.
I have read some stuff about mod_rewrite solutions, but I don't think
this is really what I need. From what I can tell, the domain is stored
in a session, and I may need to generalize it somehow, but I don't
know how to test this.
Any ideas?
Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
* And even though they are subdomains of the same domain, they are
different sites.
To get them to work with all of your subdomains, in your php.ini file set
session.cookie_domain = .example.com
where example.com is your main domain. *The leading period is important.
...but test it first - particularly with MSIE 8 and FF3.
A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.
C.
Cookie handling is defined by the HTTP specs. *And this is correct
operation for cookies. *Any browser which doesn't accept this is
non-compliant.

But please - give details on how he should implement a single sign on or
rebind the session at runtime.

Single-sign-on:

if not authenticated at the current vhost redirect to the URL (and
hence vhost) where you do authentication, including a return URL as a
param. At authentication page, if the user presents a valid session
cookie (NB doesn't have to be PHP session cookie, indeed, it'd be
better if it didn't) then redirect back to the return URL including a
token in the params. If no valid session cookie, get them to login and
if valid, redirect back to the return URL with a token as a param.

current.example.com:

if (!authenticated($_COOKIE['auth'])) {
* if ($_GET['visa']) {
* * $decrypt=decrypt($_GET['visa']);
* * list($auth,$sent)=explode('|',$decrypt);
* * if (authenticated($auth) && (5<abs($time()-$sent)) {
* * * *set_cookie('auth',$auth);
* * }
* }
}

sso.example.com

if (authenticated($_COOKIE['sso_auth'])) {
* *$visa=encrypt($_COOKIE['sso_auth'],time());
* *$return=$_GET['return_url'] . '?visa=' . $visa;
* *header("Location: $visa");
} else if ($auth=check_credentials($_POST['username'],
$_POST['password'])) {
* *// NB deliberate assignment
* *$visa=encrypt($auth);
* *$return=$_GET['return_url'] . '?visa=' . $visa;
* *set_cookie('sso_auth',$auth);
* *header("Location: $visa");
} else {
* *print "<form action='" . $_SERVER['PHP_SELF'] . "' method='POST'>
* name: <input type = 'text' name='username'Password: <input tyoe =
'password' name='password'>
* </form>\n";
}

Here using a 5 second timeout to reduce the window for replay attacks.

Session rebinding:
If you know that a user has a session id 'ABC' on host 1, and this
shares PHP session storage mechanism with host 2, then you can force
the PHP session on host 2 to use the same session id, and thus the
same session data. This also means that the user will stay logged in
on host 1 even if they don't touch any of its URLs for longer than
than the PHP session's TTL (provided they are still interacting with
host 2), e.g.

on host 1:

require_once('some_encryption_lib.inc.php');
...
session_start();
...
$_SESSION['exported']=true;
print "<a href='http://host2.example.com/?force_session=";
print encrypt(session_id() . '|' . $_SERVER['REMOTE_HOST'] . '|' .
time()) . "'>Go to other site</a>";

on host 2

require_once('some_encryption_lib.inc.php');
...
if ($_GET['force_session']) {
* *$decrypt=decrypt($_GET['force_session']);
* *list($remote_session,$host,$sent)=explode('|',$de crypt);
* *if (($host==$_SERVER['REMOTE_HOST']) && (abs(time()-$sent)<300)) {
* * * session_id($remote_session);
* *} else {
* * * // ?
* *}
}
sesion_start();
if (!$_SESSION['exported']) {
* *// session referenced is dead - reinitialize and/or re-authenticate
}

Here I'm using the client IP and the time the link was generated to
prevent CSRF - this won't work for AOL customers, nor if the link is a
accessed more than 5 minutes after it has been generated.

C.

And exactly how dows this help with multiple subdomains? *The cookies
(including the session id cookie) aren't passed to different subdomains
unless he makes the change I suggested. *So there is no way to tell from
one subdomain to another whether the user is logged in or not.

And if he makes the change I suggested, he doesn't need all this extra
stuff.

The important part he forgot is that the sso.example.com needs to
redirect to an auth-reply handler on the original server, which then
authenticates the sso token and generates the subdomain cookie. The
data transferred between sso.example.com and subdomain.example.com
should be encrypted so that falsified data can't be sent directly to
subdomain.example.com.
The general workflow is like this:

GET subdomain.example.com/secure.php
=redirect to sso.example.com/login?domain=subdomain&url=/secure.php
The browser sends any sso.example.com cookies in this request, so
you can store login info in a cookie that only gets sent to
sso.example.com and do an immediate redirect.
=redirect to subdomain.example.com/loginHandler.php?token=abcd&url=/
secure.php
Here we get back the encrypted token from the sso server, which we
decrypt and then generate our subdomain cookie.
=redirect to subdomain.example.com/secure.php
After we validated the token and generated our subdomain cookie, we
redirect to the original page

Its a bit roundabout, but only the initial sso login should prompt the
user for a password. Subdomain specific logins will redirect a couple
times, but it'll be really quick and the user won't really notice.
Subsequent requests are already validated, so they never redirect.

I think this is how the OpenID stuff works, but i'm not sure.

As an easier alternative, you can simply set the session handler to be
memcache (or whichever shared data store), and allow more promiscuous
cookie settings like Jerry suggested.

Richard

[Jerry Stuckle]

Richard Levasseur wrote:

On Jul 29, 10:52 am, Jerry Stuckle <[e-mail]:

>C. (http://symcbean.blogspot.com/) wrote:

>>On Jul 27, 3:59 pm, Jerry Stuckle <[e-mail]:
C. (http://symcbean.blogspot.com/) wrote:
On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:
>Josh wrote:
>>I run a Joomla website and am familiar with php in some but not all
>>aspects. Currently I am trying to find some solutions related to
>>session handling.
>>Am I correct in saying that "login" is kept in sessions? I can see
>>active sessions in my mysql database, but is that the only place this
>>information is stored? Sessions and cookies I know are related also,
>>but how specifically (session info stored in cookies?)?
>>Right now, when users login at example.com, and then visit
>>subdomain.example.com, they are not logged in at the subdomain. I am
>>trying to change this so that users logged in on the main site or any
>>subdomain are also logged in across all other subdomains and the main
>>site. I know sites like livejournal successfully accomplish this.
>>I have read some stuff about mod_rewrite solutions, but I don't think
>>this is really what I need. From what I can tell, the domain is stored
>>in a session, and I may need to generalize it somehow, but I don't
>>know how to test this.
>>Any ideas?
>Your problem is the session id is kept in a cookie. However, the browser
>will not normally send a cookie from one website to a different website.
> And even though they are subdomains of the same domain, they are
>different sites.
>To get them to work with all of your subdomains, in your php.ini file set
>session.cookie_domain = .example.com
>where example.com is your main domain. The leading period is important.
...but test it first - particularly with MSIE 8 and FF3.
A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.
C.
Cookie handling is defined by the HTTP specs. And this is correct
operation for cookies. Any browser which doesn't accept this is
non-compliant.
But please - give details on how he should implement a single sign on or
rebind the session at runtime.
Single-sign-on:
if not authenticated at the current vhost redirect to the URL (and
hence vhost) where you do authentication, including a return URL as a
param. At authentication page, if the user presents a valid session
cookie (NB doesn't have to be PHP session cookie, indeed, it'd be
better if it didn't) then redirect back to the return URL including a
token in the params. If no valid session cookie, get them to login and
if valid, redirect back to the return URL with a token as a param.
current.example.com:
if (!authenticated($_COOKIE['auth'])) {
if ($_GET['visa']) {
$decrypt=decrypt($_GET['visa']);
list($auth,$sent)=explode('|',$decrypt);
if (authenticated($auth) && (5<abs($time()-$sent)) {
set_cookie('auth',$auth);
}
}
}
sso.example.com
if (authenticated($_COOKIE['sso_auth'])) {
$visa=encrypt($_COOKIE['sso_auth'],time());
$return=$_GET['return_url'] . '?visa=' . $visa;
header("Location: $visa");
} else if ($auth=check_credentials($_POST['username'],
$_POST['password'])) {
// NB deliberate assignment
$visa=encrypt($auth);
$return=$_GET['return_url'] . '?visa=' . $visa;
set_cookie('sso_auth',$auth);
header("Location: $visa");
} else {
print "<form action='" . $_SERVER['PHP_SELF'] . "' method='POST'>
name: <input type = 'text' name='username'Password: <input tyoe =
'password' name='password'>
</form>\n";
}
Here using a 5 second timeout to reduce the window for replay attacks.
Session rebinding:
If you know that a user has a session id 'ABC' on host 1, and this
shares PHP session storage mechanism with host 2, then you can force
the PHP session on host 2 to use the same session id, and thus the
same session data. This also means that the user will stay logged in
on host 1 even if they don't touch any of its URLs for longer than
than the PHP session's TTL (provided they are still interacting with
host 2), e.g.
on host 1:
require_once('some_encryption_lib.inc.php');
...
session_start();
...
$_SESSION['exported']=true;
print "<a href='http://host2.example.com/?force_session=";
print encrypt(session_id() . '|' . $_SERVER['REMOTE_HOST'] . '|' .
time()) . "'>Go to other site</a>";
on host 2
require_once('some_encryption_lib.inc.php');
...
if ($_GET['force_session']) {
$decrypt=decrypt($_GET['force_session']);
list($remote_session,$host,$sent)=explode('|',$dec rypt);
if (($host==$_SERVER['REMOTE_HOST']) && (abs(time()-$sent)<300)) {
session_id($remote_session);
} else {
// ?
}
}
sesion_start();
if (!$_SESSION['exported']) {
// session referenced is dead - reinitialize and/or re-authenticate
}
Here I'm using the client IP and the time the link was generated to
prevent CSRF - this won't work for AOL customers, nor if the link is a
accessed more than 5 minutes after it has been generated.
C.

And exactly how dows this help with multiple subdomains? The cookies
(including the session id cookie) aren't passed to different subdomains
unless he makes the change I suggested. So there is no way to tell from
one subdomain to another whether the user is logged in or not.

And if he makes the change I suggested, he doesn't need all this extra
stuff.

The important part he forgot is that the sso.example.com needs to
redirect to an auth-reply handler on the original server, which then
authenticates the sso token and generates the subdomain cookie. The
data transferred between sso.example.com and subdomain.example.com
should be encrypted so that falsified data can't be sent directly to
subdomain.example.com.
The general workflow is like this:

GET subdomain.example.com/secure.php
=redirect to sso.example.com/login?domain=subdomain&url=/secure.php
The browser sends any sso.example.com cookies in this request, so
you can store login info in a cookie that only gets sent to
sso.example.com and do an immediate redirect.
=redirect to subdomain.example.com/loginHandler.php?token=abcd&url=/
secure.php
Here we get back the encrypted token from the sso server, which we
decrypt and then generate our subdomain cookie.
=redirect to subdomain.example.com/secure.php
After we validated the token and generated our subdomain cookie, we
redirect to the original page

Its a bit roundabout, but only the initial sso login should prompt the
user for a password. Subdomain specific logins will redirect a couple
times, but it'll be really quick and the user won't really notice.
Subsequent requests are already validated, so they never redirect.

I think this is how the OpenID stuff works, but i'm not sure.

As an easier alternative, you can simply set the session handler to be
memcache (or whichever shared data store), and allow more promiscuous
cookie settings like Jerry suggested.

Richard

Thanks, Richard, I knew there had to be something else in there.

What a convoluted mess. I can see if it's needed across multiple
individual domains.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Josh]

On Jul 30, 6:21*am, Jerry Stuckle <[e-mail]:

Richard Levasseur wrote:

On Jul 29, 10:52 am, Jerry Stuckle <[e-mail]:

C. (http://symcbean.blogspot.com/) wrote:
On Jul 27, 3:59 pm, Jerry Stuckle <[e-mail]:
C. (http://symcbean.blogspot.com/) wrote:
On Jul 26, 3:45 am, Jerry Stuckle <[e-mail]:
Josh wrote:
>I run a Joomla website and am familiar with php in some but not all
>aspects. Currently I am trying to find some solutions related to
>session handling.
>Am I correct in saying that "login" is kept in sessions? I can see
>active sessions in my mysql database, but is that the only place this
>information is stored? Sessions and cookies I know are related also,
>but how specifically (session info stored in cookies?)?
>Right now, when users login at example.com, and then visit
>subdomain.example.com, they are not logged in at the subdomain. Iam
>trying to change this so that users logged in on the main site orany
>subdomain are also logged in across all other subdomains and the main
>site. I know sites like livejournal successfully accomplish this.
>I have read some stuff about mod_rewrite solutions, but I don't think
>this is really what I need. From what I can tell, the domain is stored
>in a session, and I may need to generalize it somehow, but I don't
>know how to test this.
>Any ideas?
Your problem is the session id is kept in a cookie. However, the browser
will not normally send a cookie from one website to a different website.
* And even though they are subdomains of the same domain, they are
different sites.
To get them to work with all of your subdomains, in your php.ini file set
session.cookie_domain = .example.com
where example.com is your main domain. *The leading period is important.
...but test it first - particularly with MSIE 8 and FF3.
A better solution might be to look at single sign on - or at least
rebinding the session id at runtime.
C.
Cookie handling is defined by the HTTP specs. *And this is correct
operation for cookies. *Any browser which doesn't accept this is
non-compliant.
But please - give details on how he should implement a single sign on or
rebind the session at runtime.
Single-sign-on:
if not authenticated at the current vhost redirect to the URL (and
hence vhost) where you do authentication, including a return URL as a
param. At authentication page, if the user presents a valid session
cookie (NB doesn't have to be PHP session cookie, indeed, it'd be
better if it didn't) then redirect back to the return URL including a
token in the params. If no valid session cookie, get them to login and
if valid, redirect back to the return URL with a token as a param.
current.example.com:
if (!authenticated($_COOKIE['auth'])) {
* if ($_GET['visa']) {
* * $decrypt=decrypt($_GET['visa']);
* * list($auth,$sent)=explode('|',$decrypt);
* * if (authenticated($auth) && (5<abs($time()-$sent)) {
* * * *set_cookie('auth',$auth);
* * }
* }
}
sso.example.com
if (authenticated($_COOKIE['sso_auth'])) {
* *$visa=encrypt($_COOKIE['sso_auth'],time());
* *$return=$_GET['return_url'] . '?visa=' . $visa;
* *header("Location: $visa");
} else if ($auth=check_credentials($_POST['username'],
$_POST['password'])) {
* *// NB deliberate assignment
* *$visa=encrypt($auth);
* *$return=$_GET['return_url'] . '?visa=' . $visa;
* *set_cookie('sso_auth',$auth);
* *header("Location: $visa");
} else {
* *print "<form action='" . $_SERVER['PHP_SELF'] . "' method='POST'>
* name: <input type = 'text' name='username'Password: <input tyoe =
'password' name='password'>
* </form>\n";
}
Here using a 5 second timeout to reduce the window for replay attacks..
Session rebinding:
If you know that a user has a session id 'ABC' on host 1, and this
shares PHP session storage mechanism with host 2, then you can force
the PHP session on host 2 to use the same session id, and thus the
same session data. This also means that the user will stay logged in
on host 1 even if they don't touch any of its URLs for longer than
than the PHP session's TTL (provided they are still interacting with
host 2), e.g.
on host 1:
require_once('some_encryption_lib.inc.php');
...
session_start();
...
$_SESSION['exported']=true;
print "<a href='http://host2.example.com/?force_session=";
print encrypt(session_id() . '|' . $_SERVER['REMOTE_HOST'] . '|' .
time()) . "'>Go to other site</a>";
on host 2
require_once('some_encryption_lib.inc.php');
...
if ($_GET['force_session']) {
* *$decrypt=decrypt($_GET['force_session']);
* *list($remote_session,$host,$sent)=explode('|',$de crypt);
* *if (($host==$_SERVER['REMOTE_HOST']) && (abs(time()-$sent)<300)) {
* * * session_id($remote_session);
* *} else {
* * * // ?
* *}
}
sesion_start();
if (!$_SESSION['exported']) {
* *// session referenced is dead - reinitialize and/or re-authenticate
}
Here I'm using the client IP and the time the link was generated to
prevent CSRF - this won't work for AOL customers, nor if the link is a
accessed more than 5 minutes after it has been generated.
C.
And exactly how dows this help with multiple subdomains? *The cookies
(including the session id cookie) aren't passed to different subdomains
unless he makes the change I suggested. *So there is no way to tell from
one subdomain to another whether the user is logged in or not.

And if he makes the change I suggested, he doesn't need all this extra
stuff.

The important part he forgot is that the sso.example.com needs to
redirect to an auth-reply handler on the original server, which then
authenticates the sso token and generates the subdomain cookie. *The
data transferred between sso.example.com and subdomain.example.com
should be encrypted so that falsified data can't be sent directly to
subdomain.example.com.

The general workflow is like this:

GET subdomain.example.com/secure.php
=redirect to sso.example.com/login?domain=subdomain&url=/secure..php
* *The browser sends any sso.example.com cookies in this request, so
you can store login info in a cookie that only gets sent to
sso.example.com and do an immediate redirect.
=redirect to subdomain.example.com/loginHandler.php?token=abcd&url=/
secure.php
* *Here we get back the encrypted token from the sso server, which we
decrypt and then generate our subdomain cookie.
=redirect to subdomain.example.com/secure.php
* *After we validated the token and generated our subdomain cookie,we
redirect to the original page

Its a bit roundabout, but only the initial sso login should prompt the
user for a password. *Subdomain specific logins will redirect a couple
times, but it'll be really quick and the user won't really notice.
Subsequent requests are already validated, so they never redirect.

I think this is how the OpenID stuff works, but i'm not sure.

As an easier alternative, you can simply set the session handler to be
memcache (or whichever shared data store), and allow more promiscuous
cookie settings like Jerry suggested.

Richard

Thanks, Richard, I knew there had to be something else in there.

What a convoluted mess. *I can see if it's needed across multiple
individual domains.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================- Hide quoted text -

- Show quoted text -

I had posted my issue in a couple forums (Joomla-related) and forgot
to post my eventual solution here.

Turns out that in Firefox, the simple step of adding the leading '.'
in front of the domain did the trick (I had been testing in IE).

In IE, however, the issue was that the cookie name as set in Joomla
was made to be dependent on the live_site. This meant that different
subdomains were producing cookies with different names. Interestingly,
FF seems not to care about cookie names, only id's and the domain. And
interestingly, IE seems not to care about cookie domains.

In any case, making both changes (the leading '.', and the set cookie
name) did the trick across browsers (IE7, IE6, IE5.5, Firefox3,
Safari3, Opera....all those I tested, worked fine).

Thanks for the input, and I hope this helps someone else if anyone
runs into the same type of problem!