Session overwritten - but why

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('SESSID');
session_id($sess_id);
session_start();

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

session_write_close();

and returns the session id and a URL to A.

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

header('Location: ' . $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('SESSID');
session_id($sess_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('session.use_cookies', 0);
ini_set('session.use_only_cookies', 0);
ini_set('session.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

Re: Session overwritten - but why

On Fri, 30 Nov 2007 16:57:18 +0100, wrote:

> 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 =3D md5(microtime());


Why do you want to do that???? microtime() is highly, highly unsuited fo=
r =

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('SESSID');
> session_id($sess_id);
> session_start();
>
> $_SESSION['blah'] =3D 'blah';
> $_SESSION['fasel'] =3D 'fasel';
> $_SESSION['blubb'] =3D 'blubb';
>
> session_write_close();
>
> and returns the session id and a URL to A.

OK, and where is the sharded storage of session data? Are both servers s=
et =

up to look at the same storage?

> A takes the URL and the session id and performs a redirect via
>
> header('Location: ' . $url . '?SESSID=3D' . $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? Yo=
u =

might be better of setting a cookie for a wildcard domain (setcookie() -=
> =

, i.e. set the doma=
in =

to '.example.com' rather then 'server1.example.com' or =

'server2.example.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 =3D $_GET['SESSID'];
> session_name('SESSID');
> session_id($sess_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 server=
s =

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 o=
wn =

sessionhandler (set_session_handler()), and use a single database server=
=

to store/retrieve session data from.
-- =

Rik Wasmus

Re: Session overwritten - but why

On 30 Nov., 18:27, "Rik Wasmus" wrote:
> On Fri, 30 Nov 2007 16:57:18 +0100, wrote:

[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('SESSID');
> > session_id($sess_id);
> > session_start();
>
> > $_SESSION['blah'] = 'blah';
> > $_SESSION['fasel'] = 'fasel';
> > $_SESSION['blubb'] = 'blubb';
>
> > session_write_close();
>
> > 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('Location: ' . $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() ->
> , i.e. set the domain
> to '.example.com' rather then 'server1.example.com' or
> 'server2.example.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('SESSID');
> > session_id($sess_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

Re: Session overwritten - but why

On 30 Nov., 18:27, "Rik Wasmus" wrote:
> On Fri, 30 Nov 2007 16:57:18 +0100, wrote:

[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('SESSID');
> > session_id($sess_id);
> > session_start();
>
> > $_SESSION['blah'] = 'blah';
> > $_SESSION['fasel'] = 'fasel';
> > $_SESSION['blubb'] = 'blubb';
>
> > session_write_close();
>
> > 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('Location: ' . $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() ->
> , i.e. set the domain
> to '.example.com' rather then 'server1.example.com' or
> 'server2.example.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('SESSID');
> > session_id($sess_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

Re: Session overwritten - but why

On 30 Nov., 14:04, j.wendelm...@carcopy.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