PHP custom session handler - garbage collection time limit

Posted on 2006-04-09
Last Modified: 2012-06-27
I am considering writing my own custom session handling as I have certain specific requirements that would be perfectly met by having custom sessions.

I have reviewed several examples of custom handlers that are available in various places on the web. They are all very similar. But I have a question about garbage collection that seems to be common to all such examples. Specifically, the garbage collection routines destroy old sessions after either 5 minutes, or 24 minutes, typically.

I am wondering if this would not in many cases destroy sessions actively in progress. It seems like this time is very short, and so I am guessing that there must be some factor I am not aware of that makes these time limits reasonable.

Please comment on how this is really supposed to work.
Question by:jasimon9
    LVL 4

    Expert Comment

    The time limit you see refers to a timer which is *reset* each time the user visits a new page. If your session handler destroys sessions which are 5 minutes old, for example, that just means sessions for people who haven't navigated anywhere in the site for 5 minutes. People can maintain their session as long as they like as long as they keep visiting new pages, which resets the timer to zero each time. In this way only inactive sessions are destroyed.

    I hope I understood your question correctly; if not, please clarify, because I'd hate to be just repeating what you already know.

    Author Comment

    I think you are understanding the question correctly. However, this issue seems exactly what I am considering to be a problem!

    If someone comes to a page and has a session going, then is inactive for 10 minutes and is thrown out of their session, I consider that to be a big issue. I would want something much longer, say between 20 or 30 minutes.

    Compare this requirement against another feature we have: login cookies. A significant portion of our site's purpose is only available to logged in users. However, we place a cookie on the users system to remember that user, and automatically log them in when they return to the page. I originally designed these cookies to expire in 30 days.

    However, our sales dept says "why ever have them expire?" They are pushing for at least 60 or 90 days.

    So, to have sessions expire and force the user to start over again is inconsistent with this practice.

    I guess I would compare this custom session behavior to the behavior of the default session handling provided by PHP, which we are now using. The session.gc_maxlifetime is 1440 seconds. It would seem that therefore 1440 seconds should be workable, which is 24 minutes, or something like that.
    LVL 4

    Accepted Solution

    Well, I guess I'm not sure what the problem is, then, since you said above that some of the custom handlers you have reviewed do in fact have 24-minute session limits, which places it right in your ideal range. (Almost any custom session-handling script or class should also permit you to specify yourself what the limit is with a simple change of one number in the code.) So if your problem is just that they're too short, it should be rather simple to make them longer.

    However, it's very important that they expire at SOME point! Sessions contain more critical data than cookies, and so if someone is logging into your site from, say, a cybercafe, and doesn't log out, then someone else can come along a day later and continue the session, buying stuff on their credit card, posting messages, etc etc etc. Plus the longer a session time is, the more vulnerable it becomes to hackers who actually hijack sessions remotely.

    So go ahead and boost the time, but don't go crazy.

    Author Comment

    Your comment is helpfulI would prefer to see some additional comment before awarding points.

    I would proably feel ok with the 24-30 minutes, as that is what we are using during prototyping and it has not caused a problem this far.

    Featured Post

    How your wiki can always stay up-to-date

    Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
    - Increase transparency
    - Onboard new hires faster
    - Access from mobile/offline

    Join & Write a Comment

    Introduction HTML checkboxes provide the perfect way for a web developer to receive client input when the client's options might be none, one or many.  But the PHP code for processing the checkboxes can be confusing at first.  What if a checkbox is…
    Password hashing is better than message digests or encryption, and you should be using it instead of message digests or encryption.  Find out why and how in this article, which supplements the original article on PHP Client Registration, Login, Logo…
    The viewer will learn how to create and use a small PHP class to apply a watermark to an image. This video shows the viewer the setup for the PHP watermark as well as important coding language. Continue to Part 2 to learn the core code used in creat…
    This tutorial will teach you the core code needed to finalize the addition of a watermark to your image. The viewer will use a small PHP class to learn and create a watermark.

    755 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now