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 -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
