[thelist] PHP sessions timing out

Charles Stuart cs at enure.net
Sat May 21 19:20:24 CDT 2005


Thank you very much for this tip. We'll be trying it out.


best,

Charles







On May 2, 2005, at 7:48 AM, Simon Willison wrote:

>
> On 2 May 2005, at 14:52, Juha Suni wrote:
>
>
>> A rather easy and solid solution should be to set your script to  
>> store it's sessions elsewhere, where others scripts's garbage  
>> collection is not messing around. Another way is to globally  
>> increase the gc_maxlifetime from php.ini, but that might not be an  
>> option on shared hosting.
>>
>>
>
> I've always avoided PHP's built in session stuff for production  
> code for pretty much exactly this reason. Instead, I prefer to roll  
> my own. I have a sesssions table somewhere that looks a bit like this:
>
> session_id | user_id | date_and_time_they_logged_in
>
> The session_id is a randomly generated string, long enough to be  
> "secure". When a user logs in, I create a random session_id, send  
> it to them as a cookie and record that along with their user ID and  
> the date/time in the database table. Whenever I get a hit to a page  
> from someone with a session_id in their cookie, I compare it  
> against the table to see if they are logged in (and if they are,  
> load up their user details). The date_and_time_they_logged_in thing  
> is handy as well as you can enforce things like sessions timing out  
> after 60 minutes, without trusting the time you set on their cookie  
> (which can be altered by the user).
>
> If you want to be really smart, you can add a  
> date_and_time_of_last_time_the_user_loaded_a_page_anywhere_on_the_site 
>  field, and then use that to display a list of users active in the  
> last 10 minutes for "who's online" style functionality.
>
> I'm convinced that sessions based only on the user_id are The Right  
> Way To Do It. You end up having to run one database query per page  
> loaded to grab the user details which for the vast majority of  
> sites is an insignificant performance hit, but you gain the bonus  
> that info about the user is "live". A classic problem with storing  
> all sorts of information about the user in some session object  
> somewhere is that if you ban a user or remove one of their  
> permissions their session object won't automatically be updated, so  
> if they're currently logged in to the application they'll be able  
> to do things that they shouldn't.
>
> All database table names are for illustrative purposes only ;)
>
> Cheers,
>
> Simon Willison
> http://simon.incutio.com/
>
> -- 
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvesterand  
> archives of thelist go to: http://lists.evolt.orgWorkers of the  
> Web, evolt !
>
>



More information about the thelist mailing list