| 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:
|
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.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]