TYPO3 Core

I don't see the problem and I can not see how the patch should change the behaviour.
What is the wanted feature? Sessions that never timed out? Why?

Please explain me.

greetings
René

The problem is related to frontend users who are logged in. If the TYPO3_CONF_VAR for the cookie lifetime is set to one week (or anything longer than 6000 seconds) you'd expect the login to work for the lifetime of the cookie. Instead, the session is deleted after 6000 seconds and the login is no longer valid.

Applying this patch makes the session timeout equal to the lifetime of the cookie so that a user stays logged in as long as the cookie is valid.

I also don't understand why this patch should solve the issue.
The lifetime of an FE user is already set in tslib_fe.php, line 514 - right after tslib_feUserAuth has been initiated.

What I wonder much more is how you come to the value of 6000 seconds?

As far as I can remember, the problem you are having here is caused by the garbage collector in t3lib_userauth (->gc() ) which cleans all sessions older than 24 hours (86400 seconds).

Maybe the patch should instead change this value?

The garbage collector was my first though too, but after investigating we found that sessions were deleted much sooner than 24 hours.

It wasn't very clear from my description or the patch, but the 6000 seconds actually comes from auth_timeout_field on line 104 of class.tslib_feuserauth.php. The patch simply adds a constructor that overrides this hard coded value with the cookie lifetime for TYPO3_CONF_VARS.

If you look at lines 625-647 of class.t3lib_userauth.php, you'll see that auth_timeout_field is added to the current session timestamp to determine whether a user should be logged off. If the cookie's lifetime was used here instead, after being set in the constructor, then the user would not be logged off until the cookie expired.

What I don't get from the notes attached here is, whether the garbage collector is an issue, or not. If sessions get removed after 24 hours, the cookie lifetime use would still be useless when using times lomnger than 24 hours. Or does the GC check for the intended lifetime already?

Karsten,
You are correct. The garbage collector does not account for cookie lifetimes so valid, logged in users have their sessions expired after 24 hours due to the garbage collector even if the cookie lifetime is longer.

I've added a new version of the patch that sets the garbage collection time to auth_timeout_field (the cookie lifetime) when garbage collection time is sooner than the login expiration. There's a little bit of time conversion in there because auth_timeout_field is in seconds while gc_time is in hours.

Thanks,
Jeff

I coded an autologin service for the 4.0 branch lately and also stumbeled over the problem with the 6000? (3600 actually) seconds. The ->gc() is new to me, but would explain the issues of some users.
What I'm missing when just setting FE[lifetime] is, that every FEuser has autologin. So I wrote an authservice that applies this on user basis with a simple checkbox set when he logs in.

But a major problem still is, that auth-services can't overwrite the cookie lifetime. This currently only works with xclassing - and a service is not intended to xclass something, is it?

I startet a discussion on dev-list on 23.05.2006 - but got no feedback so far. I could also publish my current auth-service.

I've made another attempt to fix this problem, however this is completely untested yet:

- gc_time in class.t3lib_userauth has been turned from hours into seconds (more logical because all other fields use seconds too)
- The default of gc_time has been set from 24 (hours) to 0 which now means: use value of $this->auth_timeout_field or 1 day (like before) if that is not set.
- Changed the gc_probability check from <= to == (that was a bug I suppose)
- Do the same like your patch, but use method name "start" instead of the constructor (make sure that start() is called after this one)

Just tried it out and discovered that I've used $this->timeout instead of $this->auth_timeout_field.

Additionally I've changed the commends slightly to clarify that $this->auth_timeout_field is the servers session timeout while $this->lifetime is the clients session timeout.

Hi Michael,
I just reviewed your patch and I have a short remark:

"Changed the gc_probability check from <= to (that was a bug I suppose)"
-> no, that was no bug. gc_proboability contains a percentage value, and the comparison needs to be <=. If you set there, then the proboability that the garbage collector is being called is always 1 percent, no matter what gc_proboability is set to.

Besides that, I think it will work correctly, anyways, it is a bit hard to test.

Greets, Sebastian

Makes sense, yes. I will upload a new version of the patch...

Will not be fixed in TYPO3 4.0.2 but has been committed for 4.1.0 and later.