Home »
Imported messages »
comp.lang.php »
PEAR Auth package woes
| 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:
|
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.
|
|
|
|
Current Time: Mon Feb 17 17:51:56 GMT 2025
Total time taken to generate the page: 0.04671 seconds
Calendar
Search
Help
Members
Register
Login
Home
]