Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6297 > unrolled thread

PEAR Auth package woes

Back to article view | Back to comp.lang.php

Contents

  PEAR Auth package woes Eli the Bearded <*@eli.users.panix.com> - 2012-06-12 00:32 +0000
    Re: PEAR Auth package woes Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-11 20:34 -0400
      Re: PEAR Auth package woes Eli the Bearded <*@eli.users.panix.com> - 2012-06-12 17:38 +0000
        Re: PEAR Auth package woes The Natural Philosopher <tnp@invalid.invalid> - 2012-06-12 18:53 +0100
          Re: PEAR Auth package woes Eli the Bearded <*@eli.users.panix.com> - 2012-06-12 20:03 +0000
            Re: PEAR Auth package woes The Natural Philosopher <tnp@invalid.invalid> - 2012-06-12 21:20 +0100
        Re: PEAR Auth package woes Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-12 15:05 -0400
          Re: PEAR Auth package woes Eli the Bearded <*@eli.users.panix.com> - 2012-06-12 19:59 +0000
            Re: PEAR Auth package woes Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-12 19:32 -0400
        Re: PEAR Auth package woes "J.O. Aho" <user@example.net> - 2012-06-13 07:52 +0200
          Re: PEAR Auth package woes Eli the Bearded <*@eli.users.panix.com> - 2012-06-13 21:51 +0000
            Re: PEAR Auth package woes Jerry Stuckle <jstucklex@attglobal.net> - 2012-06-13 20:58 -0400
    Re: PEAR Auth package woes spekkionu <spekkionu@spekkionu.com> - 2012-08-18 21:02 -0700
      Re: PEAR Auth package woes The Natural Philosopher <tnp@invalid.invalid> - 2012-08-19 12:31 +0100
      Re: PEAR Auth package woes Jerry Stuckle <jstucklex@attglobal.net> - 2012-08-19 09:55 -0400

#6297 — PEAR Auth package woes

I've looked over the (sparse) docs here:

http://pear.php.net/manual/en/package.authentication.php

And I can find no mention of using this in a multiple webserver
configuration, that is N web servers (possibly with M database
servers) for N > 1 all trying to use the same authentication
cookies.

In my experiments with N=4 and M=1, I cannot get the servers
to recognize cookies set by other servers. I only used this
package instead of writing my own because I was assured it did
work for the M=1 case. Unfortunately the person who gave me
that advice is not available to talk to for another week or so.

Is there some secret setting to get this to work?

My configuration looks like this:

function loginFunction($username, $status, $auth) {
	// make a login page then exit so nothing else gets shown
	exit;
}


$options = array(
                      'dsn'         =>  $dsn,
                      'usernamecol' =>  'username',
                      'passwordcol' =>  'password',
                      'table'       =>  'site_auth',
                      'db_fields'   =>  array('name',
					'company',
					'user_id'),
                      'cryptType'   =>  'crypt',
                      'db_options'  =>  array('portability' =>
					MDB2_PORTABILITY_ALL ^
					MDB2_PORTABILITY_FIX_CASE)
                      );

$a = new Auth("MDB2", $options, "loginFunction", $optional);

$a->start();

/* problem: only get here if they've logged in on THIS server */

Elijah
------
has solved this problem before in PHP using encrypt info in cookies

[toc] | [next] | [standalone]

#6298

On 6/11/2012 8:32 PM, Eli the Bearded wrote:
> I've looked over the (sparse) docs here:
>
> http://pear.php.net/manual/en/package.authentication.php
>
> And I can find no mention of using this in a multiple webserver
> configuration, that is N web servers (possibly with M database
> servers) for N>  1 all trying to use the same authentication
> cookies.
>
> In my experiments with N=4 and M=1, I cannot get the servers
> to recognize cookies set by other servers. I only used this
> package instead of writing my own because I was assured it did
> work for the M=1 case. Unfortunately the person who gave me
> that advice is not available to talk to for another week or so.
>
> Is there some secret setting to get this to work?
>
> My configuration looks like this:
>
> function loginFunction($username, $status, $auth) {
> 	// make a login page then exit so nothing else gets shown
> 	exit;
> }
>
>
> $options = array(
>                        'dsn'         =>   $dsn,
>                        'usernamecol' =>   'username',
>                        'passwordcol' =>   'password',
>                        'table'       =>   'site_auth',
>                        'db_fields'   =>   array('name',
> 					'company',
> 					'user_id'),
>                        'cryptType'   =>   'crypt',
>                        'db_options'  =>   array('portability' =>
> 					MDB2_PORTABILITY_ALL ^
> 					MDB2_PORTABILITY_FIX_CASE)
>                        );
>
> $a = new Auth("MDB2", $options, "loginFunction", $optional);
>
> $a->start();
>
> /* problem: only get here if they've logged in on THIS server */
>
> Elijah
> ------
> has solved this problem before in PHP using encrypt info in cookies

That's because cookies are only sent to the originating domain for 
security reasons.

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

[toc] | [prev] | [next] | [standalone]

#6306

In comp.lang.php, Jerry Stuckle  <jstucklex@attglobal.net> wrote:
> On 6/11/2012 8:32 PM, Eli the Bearded wrote:
[snip, see previous article]
> That's because cookies are only sent to the originating domain for 
> security reasons.

You totally missed the problem, so perhaps I didn't explain it properly.
I have one web site that is served by four web servers for redundancy:
two colos with two machines per colo. The intent is to reduce the chance
of a single point of failure taking down the site.

All four webservers are responding to the same hostname. There are
two IP addresses, one per colo, and load balancing between servers
within each colo.

I've been using this setup just fine for years, but now I want a small
password protected area. Using the PEAR Auth package I've created it,
but cookies set on web-server-1.colo-1.internal.name do not work on
web-server-2.colo-1.internal.name or web-server-3.colo-2.internal.name.

For testing purposes I've made the Auth package talk to a single
database server, thus introducing a single point of failure into this
section of the site, but that has not helped. Login works on all
four machines, and when I pull DNS tricks to make all my traffic go
to any single machine of the four, the Auth works. As soon as I jump
to another host, it wants me to login again. With a 600s TTL on the
DNS, jumping between colos happens fairly quickly, so I can't just
rely on the load balancers providing stickiness.

Is there a way to get the Auth package to accept it's own cookies
that just happen to have been set on a different server? If so, how?

Elijah
------
posted a code snippet up-thread

[toc] | [prev] | [next] | [standalone]

#6307

Eli the Bearded wrote:
> In comp.lang.php, Jerry Stuckle  <jstucklex@attglobal.net> wrote:
>> On 6/11/2012 8:32 PM, Eli the Bearded wrote:
> [snip, see previous article]
>> That's because cookies are only sent to the originating domain for 
>> security reasons.
> 
> You totally missed the problem, so perhaps I didn't explain it properly.
> I have one web site that is served by four web servers for redundancy:
> two colos with two machines per colo. The intent is to reduce the chance
> of a single point of failure taking down the site.
> 
> All four webservers are responding to the same hostname. There are
> two IP addresses, one per colo, and load balancing between servers
> within each colo.
> 
> I've been using this setup just fine for years, but now I want a small
> password protected area. Using the PEAR Auth package I've created it,
> but cookies set on web-server-1.colo-1.internal.name do not work on
> web-server-2.colo-1.internal.name or web-server-3.colo-2.internal.name.
> 
> For testing purposes I've made the Auth package talk to a single
> database server, thus introducing a single point of failure into this
> section of the site, but that has not helped. Login works on all
> four machines, and when I pull DNS tricks to make all my traffic go
> to any single machine of the four, the Auth works. As soon as I jump
> to another host, it wants me to login again. With a 600s TTL on the
> DNS, jumping between colos happens fairly quickly, so I can't just
> rely on the load balancers providing stickiness.
> 
> Is there a way to get the Auth package to accept it's own cookies
> that just happen to have been set on a different server? If so, how?
> 

I think at this point I would scrap sessions/specialised package code 
and set a custom cookie and store it in a database common to or 
propagated across all the servers.

The generic flow is then:

is a auth cookie set
  if so is it a valid one (check database)
    if so reissue a new one and propagate it
  else present new login (our session has tied out) and post to self
else present new login (you must login to access this part of the site) 
and post to self





> Elijah
> ------
> posted a code snippet up-thread
> 


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#6313

In comp.lang.php, The Natural Philosopher  <tnp@invalid.invalid> wrote:
> Eli the Bearded wrote:
>> Is there a way to get the Auth package to accept it's own cookies
>> that just happen to have been set on a different server? If so, how?
> I think at this point I would scrap sessions/specialised package code 
> and set a custom cookie and store it in a database common to or 
> propagated across all the servers.

I know how to do this, without even incuring a database hit on
the other servers. I have used cookies with encrypted content for
this purpose before. I'm not looking to reinvent the wheel, just
trying to get this package to work for me.

Elijah
------
library code is supposed to make life easier

[toc] | [prev] | [next] | [standalone]

#6314

Eli the Bearded wrote:
> In comp.lang.php, The Natural Philosopher  <tnp@invalid.invalid> wrote:
>> Eli the Bearded wrote:
>>> Is there a way to get the Auth package to accept it's own cookies
>>> that just happen to have been set on a different server? If so, how?
>> I think at this point I would scrap sessions/specialised package code 
>> and set a custom cookie and store it in a database common to or 
>> propagated across all the servers.
> 
> I know how to do this, without even incuring a database hit on
> the other servers. I have used cookies with encrypted content for
> this purpose before. I'm not looking to reinvent the wheel, just
> trying to get this package to work for me.
> 
> Elijah
> ------
> library code is supposed to make life easier

Indeed.

But when it doesn't - and in my case its usually after three aborted 
attempts to make it work, I simply write my own.

I've spent more time replying to you than I did coding my solution some 
months ago.

OTOH I do accept getting it debugged took a bit longer.


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#6309

On 6/12/2012 1:38 PM, Eli the Bearded wrote:
> In comp.lang.php, Jerry Stuckle<jstucklex@attglobal.net>  wrote:
>> On 6/11/2012 8:32 PM, Eli the Bearded wrote:
> [snip, see previous article]
>> That's because cookies are only sent to the originating domain for
>> security reasons.
>
> You totally missed the problem, so perhaps I didn't explain it properly.
> I have one web site that is served by four web servers for redundancy:
> two colos with two machines per colo. The intent is to reduce the chance
> of a single point of failure taking down the site.
>
> All four webservers are responding to the same hostname. There are
> two IP addresses, one per colo, and load balancing between servers
> within each colo.
>
> I've been using this setup just fine for years, but now I want a small
> password protected area. Using the PEAR Auth package I've created it,
> but cookies set on web-server-1.colo-1.internal.name do not work on
> web-server-2.colo-1.internal.name or web-server-3.colo-2.internal.name.
>
> For testing purposes I've made the Auth package talk to a single
> database server, thus introducing a single point of failure into this
> section of the site, but that has not helped. Login works on all
> four machines, and when I pull DNS tricks to make all my traffic go
> to any single machine of the four, the Auth works. As soon as I jump
> to another host, it wants me to login again. With a 600s TTL on the
> DNS, jumping between colos happens fairly quickly, so I can't just
> rely on the load balancers providing stickiness.
>
> Is there a way to get the Auth package to accept it's own cookies
> that just happen to have been set on a different server? If so, how?
>
> Elijah
> ------
> posted a code snippet up-thread
>

No, I didn't miss the problem.  It's not the package not accepting the 
cookies - the browser won't send a cookie to a domain other than the one 
it was loaded from.  So a cookie set on your first host, the browser 
won't send the cookie to the second host.  This is for security reasons. 
  And the PEAR Auth routines use cookies to maintain the authentication 
information.  This is why it worked when you fooled with the DNS and 
failed when you had different subdomains.

Now, if the are all on the same domain but different domains, i.e. 
www1.example.com and www2.example.com, you can use 
session_set_cookie_params() to set the domain for the session cookie so 
that it will be sent to any of the subdomains.  For a single cookie, you 
would use setcookie().

But I also don't know if you can use it with the PEAR routines.



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

[toc] | [prev] | [next] | [standalone]

#6312

In comp.lang.php, Jerry Stuckle  <jstucklex@attglobal.net> wrote:
> On 6/12/2012 1:38 PM, Eli the Bearded wrote:
> > You totally missed the problem, so perhaps I didn't explain it properly.
> No, I didn't miss the problem.  It's not the package not accepting the 
> cookies - the browser won't send a cookie to a domain other than the one 
> it was loaded from.  So a cookie set on your first host, the browser 

Do you think that www.google.com is a single computer? How about
www.yahoo.com? Or www.just-about-any-big.site? Do you know what
load balancing is? I do not think you do.

Elijah
------
tempted to reach for the plonk

[toc] | [prev] | [next] | [standalone]

#6315

On 6/12/2012 3:59 PM, Eli the Bearded wrote:
> In comp.lang.php, Jerry Stuckle<jstucklex@attglobal.net>  wrote:
>> On 6/12/2012 1:38 PM, Eli the Bearded wrote:
>>> You totally missed the problem, so perhaps I didn't explain it properly.
>> No, I didn't miss the problem.  It's not the package not accepting the
>> cookies - the browser won't send a cookie to a domain other than the one
>> it was loaded from.  So a cookie set on your first host, the browser
>
> Do you think that www.google.com is a single computer? How about
> www.yahoo.com? Or www.just-about-any-big.site? Do you know what
> load balancing is? I do not think you do.
>
> Elijah
> ------
> tempted to reach for the plonk

No - but they all have the same domain name, and have a load balancing 
server.  All "working" servers have the same domain name - which is NOT 
the same as what you have.

And yes, I know what load balancing is - I first got introduced to it 
when I was working with IBM in the mid-1980's.  Probably a few years 
before you were born.

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

[toc] | [prev] | [next] | [standalone]

#6317

Eli the Bearded wrote:

> I've been using this setup just fine for years, but now I want a small
> password protected area. Using the PEAR Auth package I've created it,
> but cookies set on web-server-1.colo-1.internal.name do not work on
> web-server-2.colo-1.internal.name or web-server-3.colo-2.internal.name.

I haven't used the PEAR Auth package, but the problem is your cookies, as each 
has their own subdomain, which makes machine A can't read machine B's cookie, 
and machines from Colo1 can't read cookies from Colo2.

You need to see to that the PEAR Auth will be using internal.name as the 
domain name.

Until you have fixed that, there is no way you will get it to work.
I suggest you submit the patch upstream when you have fixed it, so someone 
else who wants to use PEAR Auth in the same way as you, can do it too.


-- 

   //Aho

[toc] | [prev] | [next] | [standalone]

#6322

In comp.lang.php, J.O. Aho <user@example.net> wrote:
> I haven't used the PEAR Auth package, but the problem is your cookies,
> as each has their own subdomain, which makes machine A can't read
> machine B's cookie, and machines from Colo1 can't read cookies from Colo2.

Bullshit. Each has their own subdomain when viewed from the inside
interface, but not when reached through the load balancer.

I can telnet to machine A, get a cookie, then telnet to machine A and
have teh cookie accepted or telnet to machine B and have the cookie
rejected.  There is no "can't read cookies" entering into this.

$ telnet web-3 80
POST /monitoring.php HTTP/1.0
Host: OBSCURED
Content-Type: application/x-www-form-urlencoded
Content-Length: 40

username=OBSCURED&password=OBSCURED
HTTP/1.1 200 OK
Date: Wed, 13 Jun 2012 21:27:41 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.7
Set-Cookie: PHPSESSID=fbp8hencd7pqat7kma9tbn3ek3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=r8gv0iggn0km0igms00mc785k4; path=/
Set-Cookie: authchallenge=e09d912dca24f955c5dc5abcf6e6809e; path=/
Vary: Accept-Encoding
Content-Length: 260
Connection: close
Content-Type: text/html

[...]
GOOD: All Worked
Connection closed by foreign host.
$

See the double Set-Cookie: PHPSESSID=(foo) there? That's quirky,
but if you play "last seen wins" then the cookies are usable, on
the same host:

$ telnet web-3 80
GET /monitoring.php HTTP/1.0
Host: OBSCURED
Cookie: PHPSESSID=r8gv0iggn0km0igms00mc785k4; authchallenge=e09d912dca24f955c5dc5abcf6e6809e

HTTP/1.1 200 OK
Date: Wed, 13 Jun 2012 21:28:36 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.7
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 260
Connection: close
Content-Type: text/html

[...]
GOOD: All Worked
Connection closed by foreign host.
$

Now try that cookie on another machine:

$ telnet web-4 80
GET /monitoring.php HTTP/1.0
Host: OBSCURED
Cookie: PHPSESSID=r8gv0iggn0km0igms00mc785k4; authchallenge=e09d912dca24f955c5dc5abcf6e6809e

HTTP/1.1 200 OK
Date: Wed, 13 Jun 2012 21:29:19 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.7
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Length: 4694
Connection: close
Content-Type: text/html

[... login page is presented ...]
Connection closed by foreign host.
$

This is pure and simple, Auth doesn't like it's own cookies when set
by another machine. Is it fixable with some hidden setting? That part
I have not been able to find out, and I suspect the answer is no.

Elijah
------
thinks most web programmers don't know how to think in loadbalanced terms

[toc] | [prev] | [next] | [standalone]

#6323

On 6/13/2012 5:51 PM, Eli the Bearded wrote:
> In comp.lang.php, J.O. Aho<user@example.net>  wrote:
>> I haven't used the PEAR Auth package, but the problem is your cookies,
>> as each has their own subdomain, which makes machine A can't read
>> machine B's cookie, and machines from Colo1 can't read cookies from Colo2.
>
> Bullshit. Each has their own subdomain when viewed from the inside
> interface, but not when reached through the load balancer.
>

Bullshit.  The programmers here know how load balancers work.  You have 
very obviously shown YOU DO NOT.

> I can telnet to machine A, get a cookie, then telnet to machine A and
> have teh cookie accepted or telnet to machine B and have the cookie
> rejected.  There is no "can't read cookies" entering into this.
>

telnet is NOT a browser!!

> $ telnet web-3 80
> POST /monitoring.php HTTP/1.0
> Host: OBSCURED
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 40
>
> username=OBSCURED&password=OBSCURED
> HTTP/1.1 200 OK
> Date: Wed, 13 Jun 2012 21:27:41 GMT
> Server: Apache/2.2.14 (Ubuntu)
> X-Powered-By: PHP/5.3.2-1ubuntu4.7
> Set-Cookie: PHPSESSID=fbp8hencd7pqat7kma9tbn3ek3; path=/
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Pragma: no-cache
> Set-Cookie: PHPSESSID=r8gv0iggn0km0igms00mc785k4; path=/
> Set-Cookie: authchallenge=e09d912dca24f955c5dc5abcf6e6809e; path=/
> Vary: Accept-Encoding
> Content-Length: 260
> Connection: close
> Content-Type: text/html
>
> [...]
> GOOD: All Worked
> Connection closed by foreign host.
> $
>

Totally immaterial.

> See the double Set-Cookie: PHPSESSID=(foo) there? That's quirky,
> but if you play "last seen wins" then the cookies are usable, on
> the same host:
>
> $ telnet web-3 80
> GET /monitoring.php HTTP/1.0
> Host: OBSCURED
> Cookie: PHPSESSID=r8gv0iggn0km0igms00mc785k4; authchallenge=e09d912dca24f955c5dc5abcf6e6809e
>
> HTTP/1.1 200 OK
> Date: Wed, 13 Jun 2012 21:28:36 GMT
> Server: Apache/2.2.14 (Ubuntu)
> X-Powered-By: PHP/5.3.2-1ubuntu4.7
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Pragma: no-cache
> Vary: Accept-Encoding
> Content-Length: 260
> Connection: close
> Content-Type: text/html
>
> [...]
> GOOD: All Worked
> Connection closed by foreign host.
> $
>
> Now try that cookie on another machine:
>
> $ telnet web-4 80
> GET /monitoring.php HTTP/1.0
> Host: OBSCURED
> Cookie: PHPSESSID=r8gv0iggn0km0igms00mc785k4; authchallenge=e09d912dca24f955c5dc5abcf6e6809e
>
> HTTP/1.1 200 OK
> Date: Wed, 13 Jun 2012 21:29:19 GMT
> Server: Apache/2.2.14 (Ubuntu)
> X-Powered-By: PHP/5.3.2-1ubuntu4.7
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Pragma: no-cache
> Vary: Accept-Encoding
> Content-Length: 4694
> Connection: close
> Content-Type: text/html
>
> [... login page is presented ...]
> Connection closed by foreign host.
> $
>

Totally immaterial.

> This is pure and simple, Auth doesn't like it's own cookies when set
> by another machine. Is it fixable with some hidden setting? That part
> I have not been able to find out, and I suspect the answer is no.
>
> Elijah
> ------
> thinks most web programmers don't know how to think in loadbalanced terms

No, it is obvious you have no idea how a true load balancer (like Google 
or Yahoo uses) works.  You are trying to gimmick your own, but won't 
listen to why it isn't working.

Good luck, stoopid.  With that attitude you won't get any help here.  We 
only try to help those who are willing to learn.  You obviously are not.


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

[toc] | [prev] | [next] | [standalone]

#6813

The issue is actually more about how php stores session data than how cookies work.

By default when php stores a session it stores the serializes the data and writes it to a file in the save_path.  

As the example of the problem say a user visits a page. The request ends up on server A. A session with id abc is created (sessionid will actually be a hash but I want to save typing).  This session id is stored in a cookie and the session data is saved in a file on server A.

The user then requests a second page.  This request end up on server B.  Since the session file was created on server A and is not on server B a new session will be created and the session file will be stored on server B with none of the data from the session on server A.

There are two solutions to this problem that I know of.

The first is that some load balancing solutions support session locking which basically means that once a cookie is set for a user all future requests with that cookie will end up on the same server.  This will ensure the user will always have the same cookies and the session file will be there.  I know rackspace load balancers support this functionality (http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Manage_Session_Persistence-d1e3733.html).

The downside to this is that it reduces the effectiveness of the load balancing.

The other solution to this problem is that the default session storage of saving the session data to a file on the server will not work.  The session data needs to be stored somewhere that is accessible to all the servers.

Common solutions are using a key-value storage system as the session handler.
There are a number of options but the only one I have experience using as a session handler is redis.

With the same scenario the session will be stored in the redis database on the first request instead of a file on the server.  With the second request the session is loaded from the redis database rather than trying to find the file and will thus be able to load the session.

[toc] | [prev] | [next] | [standalone]

#6815

spekkionu wrote:
> The issue is actually more about how php stores session data than how cookies work.
> 
> By default when php stores a session it stores the serializes the data and writes it to a file in the save_path.  
> 
> As the example of the problem say a user visits a page. The request ends up on server A. A session with id abc is created (sessionid will actually be a hash but I want to save typing).  This session id is stored in a cookie and the session data is saved in a file on server A.
> 
> The user then requests a second page.  This request end up on server B.  Since the session file was created on server A and is not on server B a new session will be created and the session file will be stored on server B with none of the data from the session on server A.
> 
> There are two solutions to this problem that I know of.
> 
> The first is that some load balancing solutions support session locking which basically means that once a cookie is set for a user all future requests with that cookie will end up on the same server.  This will ensure the user will always have the same cookies and the session file will be there.  I know rackspace load balancers support this functionality (http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Manage_Session_Persistence-d1e3733.html).
> 
> The downside to this is that it reduces the effectiveness of the load balancing.
> 
> The other solution to this problem is that the default session storage of saving the session data to a file on the server will not work.  The session data needs to be stored somewhere that is accessible to all the servers.
> 
> Common solutions are using a key-value storage system as the session handler.
> There are a number of options but the only one I have experience using as a session handler is redis.
> 
> With the same scenario the session will be stored in the redis database on the first request instead of a file on the server.  With the second request the session is loaded from the redis database rather than trying to find the file and will thus be able to load the session.

If you are at this level of complexity don't use sessions, use raw 
cookies, set one per user and store in a database that is either 
replicated or accessible by all servers.

Remember: sessions are only an idiot way to access cookies. If they dont 
work for you  do it the man way :-)



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6816

On 8/19/2012 12:02 AM, spekkionu wrote:
> The issue is actually more about how php stores session data than how cookies work.
>

Incorrect.

While this can be a problem in sites where load balancing is required, 
that is not the problem here.  The problem here is trying to use the 
same cookie across multiple domains.

Load balancing is an entirely different problem, unrelated to the ops.

But then what do you expect from someone who responds with to a post 
over 2 months old?  Of course, that's also pretty normal from someone 
who uses Google Groups.

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web