Does session.gc_probability and session.gc_divisor set an equal 100% bad idea?

Question

Scenario:

• User is registered in
• Cookie set to session length
• After 1 hour of inactivity, I want to log out.

How can I solve this:

• Set session.gc_maxlifetime to 1 hour (3600)
• Set session.gc_probability to 1
• Set session.gc_divisor to 1
• Therefore, having 100% confidence that garbage collection will occur on any cookie inactivity sessions after 1 hour.

My question is:

All the posts and documentation I read about never mentioned setting the gc change to 100%, so is it bad to do this? Is there a better way?

This is a symfony application, and in the long run I would like to do something like http://symfony.com/doc/master/components/http_foundation/session_configuration.html#session-meta-data , but for now I was hoping to just do something- something simple with session.gc _ *

One post I read implies that having a 100% garbage collection is “expensive” How do I end a PHP session in 30 minutes? it's true? If so, how much does it cost?

Hooray!

Answer 1

gc_probability and gc_divisor are designed to help you determine the "likelihood" of garbage collection (GC) running.

Since GC (like everyone else) has its own cost, you usually do not want it to be executed for every web request processed by your server - this will mean that every page opening, every AJAX request, every image or JS file that is uploaded from the server will make GC work.

Thus, depending on the actual load and use of the server, the administrator must make a reasonable assumption about how often the GC should be launched: once out of 100, 1/10000 or 1 million requests.

But in the original argument of the OP there is a problem flaw - that garbage collection will occur on any idle session . As I read the manual , garbage collection will occur in ANY session, and not just in a simple one:

session.gc_maxlifetime integer : indicates the number of seconds after which data will be considered garbage and can be cleared.

Thus, the session lifetime (downtime or not) is determined using gc_maxlifetime , and the moment the GC starts (as stated in the documents: “potentially”) is really determined using gc_probability and gc_divisor .

To resume, my late answer to the question would be - I would not, under normal conditions, have GC work on every request (scenario 1/1 that you mentioned), because

1. this seems serious redundant. At some level, you will likely end up with thousands (if not worse) IFs and only once go to THEN
2. You would be logged out of ANY user in 60 minutes, and not just inactive.

Answer 2

There are much better ways to do this.

If this is not for something particularly secure, you can set the date and length of the cookie session on the client side. In this case, a technically minded user can change the expiration date, so you do not want to use it on the bank's website.

If you need something more secure, just save the expiration time along with other session data and check it out. If it is exceeded, destroy their session and make them return.