| PEAR Auth package woes [message #178375] |
Tue, 12 June 2012 00:32  |
Eli the Bearded
Messages: 22
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: PEAR Auth package woes [message #178376 is a reply to message #178375] |
Tue, 12 June 2012 00:34  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: PEAR Auth package woes [message #178384 is a reply to message #178376] |
Tue, 12 June 2012 17:38 |
Eli the Bearded
Messages: 22
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
In comp.lang.php, Jerry Stuckle <jstucklex(at)attglobal(dot)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
|
|
|
|
| Re: PEAR Auth package woes [message #178385 is a reply to message #178384] |
Tue, 12 June 2012 17:53 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Eli the Bearded wrote:
> In comp.lang.php, Jerry Stuckle <jstucklex(at)attglobal(dot)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.
|
|
|
|
| Re: PEAR Auth package woes [message #178387 is a reply to message #178384] |
Tue, 12 June 2012 19:05 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/12/2012 1:38 PM, Eli the Bearded wrote:
> In comp.lang.php, Jerry Stuckle<jstucklex(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: PEAR Auth package woes [message #178390 is a reply to message #178387] |
Tue, 12 June 2012 19:59 |
Eli the Bearded
Messages: 22
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
In comp.lang.php, Jerry Stuckle <jstucklex(at)attglobal(dot)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
|
|
|
|
| Re: PEAR Auth package woes [message #178391 is a reply to message #178385] |
Tue, 12 June 2012 20:03 |
Eli the Bearded
Messages: 22
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
In comp.lang.php, The Natural Philosopher <tnp(at)invalid(dot)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
|
|
|
|
| Re: PEAR Auth package woes [message #178392 is a reply to message #178391] |
Tue, 12 June 2012 20:20 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Eli the Bearded wrote:
> In comp.lang.php, The Natural Philosopher <tnp(at)invalid(dot)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.
|
|
|
|
| Re: PEAR Auth package woes [message #178393 is a reply to message #178390] |
Tue, 12 June 2012 23:32 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/12/2012 3:59 PM, Eli the Bearded wrote:
> In comp.lang.php, Jerry Stuckle<jstucklex(at)attglobal(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: PEAR Auth package woes [message #178395 is a reply to message #178384] |
Wed, 13 June 2012 05:52 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: PEAR Auth package woes [message #178399 is a reply to message #178395] |
Wed, 13 June 2012 21:51 |
Eli the Bearded
Messages: 22
Registered: April 2011
Karma: 0
|
Junior Member |
|
|
In comp.lang.php, J.O. Aho <user(at)example(dot)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
|
|
|
|
| Re: PEAR Auth package woes [message #178400 is a reply to message #178399] |
Thu, 14 June 2012 00:58 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/13/2012 5:51 PM, Eli the Bearded wrote:
> In comp.lang.php, J.O. Aho<user(at)example(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: PEAR Auth package woes [message #178884 is a reply to message #178375] |
Sun, 19 August 2012 04:02 |
spekkionu
Messages: 1
Registered: August 2012
Karma: 0
|
Junior Member |
|
|
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/Manag e_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.
|
|
|
|
| Re: PEAR Auth package woes [message #178886 is a reply to message #178884] |
Sun, 19 August 2012 11:31 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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/Manag e_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.
|
|
|
|
| Re: PEAR Auth package woes [message #178887 is a reply to message #178884] |
Sun, 19 August 2012 13:55 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]