Session overwritten - but why

[j.wendelmuth]

Hi,

i have a problem with PHP sessions. The problem only occurs on one
machine (PHP v5.2.4 incl. mod_security). On another one (PHP v5.2.0 no
mod security) my application works fine.

Here's the precondition:
I have 2 PHP applications, A and B. Both on a seperate server/machine.
A perfoms via SoapClient a request on B, where a Soap service is
located. B provides amongst others a function, that initializes a
session with data on B's side

$sess_id = md5(microtime() );

session_name('S ESSID');
session_id($ses s_id);
session_start() ;

$_SESSION['blah'] = 'blah';
$_SESSION['fasel'] = 'fasel';
$_SESSION['blubb'] = 'blubb';

session_write_c lose();

and returns the session id and a URL to A.

A takes the URL and the session id and performs a redirect via

header('Locatio n: ' . $url . '?SESSID=' . $sess_id). The URL
points to a script located on B's side.

When the script on B is called, it checks if a session id is given
within the URL ($_GET) and tries to start the session.

$sess_id = $_GET['SESSID'];
session_name('S ESSID');
session_id($ses s_id);
session_start() ;

As i mentioned above it works fine on the PHP v5.2.0 machine but not
on v5.2.4. After session_start() the existing session will be
overwritten with an empty one, having the same session id. I've
additionally confirmed this behaviour in the sessions directory.

I'm not using session coockies.

ini_set('sessio n.use_cookies', 0);
ini_set('sessio n.use_only_cook ies', 0);
ini_set('sessio n.use_trans_sid ', 0);

I've also compared the session parameter configuration of both servers
and there's no diff. The log files of the server give me no hint.
Can anybody give my a hint?

Thanks in advance,
der Jens

[Rik Wasmus]

On Fri, 30 Nov 2007 16:57:18 +0100, <j.**********@c arcopy.comwrote :

Hi,

i have a problem with PHP sessions. The problem only occurs on one
machine (PHP v5.2.4 incl. mod_security). On another one (PHP v5.2.0 no
mod security) my application works fine.

Here's the precondition:
I have 2 PHP applications, A and B. Both on a seperate server/machine.
A perfoms via SoapClient a request on B, where a Soap service is
located. B provides amongst others a function, that initializes a
session with data on B's side

$sess_id = md5(microtime() );

Why do you want to do that???? microtime() is highly, highly unsuited for
a busy server. At least use something like uniqid(). You basically are
asking for problems creating session-ids like this. Is there any
particular reason you want to set the session-id? Why not let PHP handle
it (and it's uniqueness at that time). If you just want to know a
session-id after it's being set just call session_id() with no arguments..

session_name('S ESSID');
session_id($ses s_id);
session_start() ;

$_SESSION['blah'] = 'blah';
$_SESSION['fasel'] = 'fasel';
$_SESSION['blubb'] = 'blubb';

session_write_c lose();

and returns the session id and a URL to A.

OK, and where is the sharded storage of session data? Are both servers set
up to look at the same storage?

A takes the URL and the session id and performs a redirect via

header('Locatio n: ' . $url . '?SESSID=' . $sess_id). The URL
points to a script located on B's side.

Using a GET is somewhat hazardous. What domains do your servers have? You
might be better of setting a cookie for a wildcard domain (setcookie() -
<http://nl2.php.net/manual/en/function.setcoo kie.php>, i.e. set the domain
to '.example.com' rather then 'server1.exampl e.com' or
'server2.exampl e.com'.

When the script on B is called, it checks if a session id is given
within the URL ($_GET) and tries to start the session.

$sess_id = $_GET['SESSID'];
session_name('S ESSID');
session_id($ses s_id);
session_start() ;

As i mentioned above it works fine on the PHP v5.2.0 machine but not
on v5.2.4. After session_start() the existing session will be
overwritten with an empty one, having the same session id. I've
additionally confirmed this behaviour in the sessions directory.

Where is this sessions directory, and how have you configured the servers
to look into one and the same directory (which can be on only 1 server,
either A or B, or an unmentioned C) for the storage?

When 'crossing' servers with sessions, I usually opt for setting up my own
sessionhandler (set_session_ha ndler()), and use a single database server
to store/retrieve session data from.
--
Rik Wasmus

[j.wendelmuth]

On 30 Nov., 18:27, "Rik Wasmus" <luiheidsgoe... @hotmail.comwro te:

On Fri, 30 Nov 2007 16:57:18 +0100, <j.wendelm...@c arcopy.comwrote :

[snip]

$sess_id = md5(microtime() );

Why do you want to do that???? microtime() is highly, highly unsuited for
a busy server. At least use something like uniqid(). You basically are
asking for problems creating session-ids like this. Is there any
particular reason you want to set the session-id? Why not let PHP handle
it (and it's uniqueness at that time). If you just want to know a
session-id after it's being set just call session_id() with no arguments.

OK, you're right. I'll change this.

session_name('S ESSID');
session_id($ses s_id);
session_start() ;

$_SESSION['blah'] = 'blah';
$_SESSION['fasel'] = 'fasel';
$_SESSION['blubb'] = 'blubb';

session_write_c lose();

and returns the session id and a URL to A.

OK, and where is the sharded storage of session data? Are both servers set
up to look at the same storage?

The A server is not looking at this storage. Server A just works as an
entry point to B. A does not need to know anything about storage of
B's sessions.

A takes the URL and the session id and performs a redirect via

header('Locatio n: ' . $url . '?SESSID=' . $sess_id). The URL
points to a script located on B's side.

Using a GET is somewhat hazardous. What domains do your servers have? You
might be better of setting a cookie for a wildcard domain (setcookie() ->
<http://nl2.php.net/manual/en/function.setcoo kie.php>, i.e. set the domain
to '.example.com' rather then 'server1.exampl e.com' or
'server2.exampl e.com'.

Ok, does it mean A (server) can sent a cookie to B (server). I'll try
it.

When the script on B is called, it checks if a session id is given
within the URL ($_GET) and tries to start the session.

$sess_id = $_GET['SESSID'];
session_name('S ESSID');
session_id($ses s_id);
session_start() ;

As i mentioned above it works fine on the PHP v5.2.0 machine but not
on v5.2.4. After session_start() the existing session will be
overwritten with an empty one, having the same session id. I've
additionally confirmed this behaviour in the sessions directory.

Where is this sessions directory, and how have you configured the servers
to look into one and the same directory (which can be on only 1 server,
either A or B, or an unmentioned C) for the storage?

As stated above, only server B has to handle the session data.

[snip]

Thanks for your hints. I'll state the result ASAP.

Best regards,
der Jens

[j.wendelmuth]

On 30 Nov., 18:27, "Rik Wasmus" <luiheidsgoe... @hotmail.comwro te:

On Fri, 30 Nov 2007 16:57:18 +0100, <j.wendelm...@c arcopy.comwrote :

[snip]

$sess_id = md5(microtime() );

Why do you want to do that???? microtime() is highly, highly unsuited for
a busy server. At least use something like uniqid(). You basically are
asking for problems creating session-ids like this. Is there any
particular reason you want to set the session-id? Why not let PHP handle
it (and it's uniqueness at that time). If you just want to know a
session-id after it's being set just call session_id() with no arguments.

OK, you're right. I'll change this.

session_name('S ESSID');
session_id($ses s_id);
session_start() ;

$_SESSION['blah'] = 'blah';
$_SESSION['fasel'] = 'fasel';
$_SESSION['blubb'] = 'blubb';

session_write_c lose();

and returns the session id and a URL to A.

OK, and where is the sharded storage of session data? Are both servers set
up to look at the same storage?

The A server is not looking at this storage. Server A just works as an
entry point to B. A does not need to know anything about storage of
B's sessions.

A takes the URL and the session id and performs a redirect via

header('Locatio n: ' . $url . '?SESSID=' . $sess_id). The URL
points to a script located on B's side.

Using a GET is somewhat hazardous. What domains do your servers have? You
might be better of setting a cookie for a wildcard domain (setcookie() ->
<http://nl2.php.net/manual/en/function.setcoo kie.php>, i.e. set the domain
to '.example.com' rather then 'server1.exampl e.com' or
'server2.exampl e.com'.

Ok, does it mean A (server) can sent a cookie to B (server). I'll try
it.

When the script on B is called, it checks if a session id is given
within the URL ($_GET) and tries to start the session.

$sess_id = $_GET['SESSID'];
session_name('S ESSID');
session_id($ses s_id);
session_start() ;

As i mentioned above it works fine on the PHP v5.2.0 machine but not
on v5.2.4. After session_start() the existing session will be
overwritten with an empty one, having the same session id. I've
additionally confirmed this behaviour in the sessions directory.

Where is this sessions directory, and how have you configured the servers
to look into one and the same directory (which can be on only 1 server,
either A or B, or an unmentioned C) for the storage?

As stated above, only server B has to handle the session data.

[snip]

Thanks for your hints. I'll state the result ASAP.

Best regards,
der Jens

[jeanmarie78]

On 30 Nov., 14:04, j.wendelm...@ca rcopy.com wrote:

[snip]

Thanks for your hints. I'll state the result ASAP.

Ok, i dropped the idea with the session storage. After a lot of
research and trial + error i decided to use a DB based storage.

In short words:
A user wants to request a service from a server B, but there's no
direct access to B available/possible/allowed. That's why B provides a
SoapService the has to be accessed by a server A. Server B receives
the Soap-Request from A and writes the affected data together with an
on the fly created token into the database. The token and the URL are
returned to A. A redirects the user via header command to URL, where
the token is send as GET parameter. The script behind the URL
validates the token and resumes the data stored in the database.

Best regards,
der Jens