At 3:53 PM +0000 3/18/11, Stuart Dallas wrote:
Hi Tedd,
Long time no chat, hope you're well.
On Friday, 18 March 2011 at 15:44, tedd wrote:
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.
If your site is being served by multiple servers you need
centralised storage of session data rather than the PHP default of
using files. Either that or the load balancer needs to use sticky
sessions which can lead to other issues depending on your traffic
patterns.
My alternative to that is to bounce the minimum amount of data
necessary between the browser and server with each request.
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.
That would be because there isn't one, but you'd be surprised how
often sessions are used for this type of thing.
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.
I don't recall anyone saying anything about reactivating old
sessions. The cookies I use to replace sessions are session-based
cookies and last no longer than a traditional PHP session. The key
is to provide a lightweight method of ensuring that whichever server
processes the request has access to the session data.
-Stuart
Thanks Stuart.
You are always a couple of light years ahead of me. I'll have to
study what you provided.
Cheers,
tedd
--
-------
http://sperling.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
