At 3:18 PM +0000 3/17/11, Stuart Dallas wrote:
> Pragmatically speaking though, I'd say go for database backed
sessions until
> they actually become a performance bottleneck.
-snip-
This may also be of interest:
http://stut.net/2008/07/26/sessionless-sessions-2/
-Stuart
--
Stuart Dallas
Stuart:
I'm not getting the reason for storing a session in a db.
In the scripts I have written that remember the user (i.e., "Hi
Stuart"), I simply use a cookie stored on the user's computer.
Sometimes it's just their name and other times it could be what/where
they visited, or how they set their defaults, or any number of
things. But everything that is needed and doesn't require
authorization is set in a cookie that expires within a specific
length of time -- usually a year.
I don't see a need for storing session in the above case.
If the scripts require an authorization, then I use sessions and a
timer in concert. As long as the authorized user remains logged-in
and the visit remains active, then the user enjoys the benefits of
the visit.
If the authorized user times out, then the session is destroyed and
the user is asked to log-in again, generating another session.
If the authorized user leaves the session (closes the browser) then
everything is closed (session destroyed) and sometimes a cookie
remains on the user's computer preparing for the next visit.
The next time the user visits the site, everything (if anything) that
is stored in user's cookie is addressed. But the user is asked to
log-in again and another session is generated.
In all cases where there is sensitive data, the user must log-in
generating a new session.
Again, I don't see how storing the current/past session provides any benefit.
So, what am I not understanding or missing?
Please show me how reactivating (if that is what this is) a session
does anything.
Thanks,
tedd
--
-------
http://sperling.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
