Hello,

I think we have uncovered a bug in the core related to session garbage collection when custom sessions are enabled (ie: when using a custom session name in the preferences).

The session class in the kernel contains this function for handling session garbage collection:



As far as I can tell, that function is called by PHP itself on a random basis, based on certain settings in the PHP ini file (by default once out of every 100 page loads). The $expire time that gets passed to it is also set in the PHP ini file (session.gc_maxlifetime). By default that time is 1440 seconds, or 24 minutes.

So, if I'm correct about that, then this function causes a problem when you have custom session settings in effect, in particular a custom expiry time.

Suppose you have a custom session expiry time of 60 minutes. Suppose you have a user who is logged in and filling in a form for a long period of time, maybe a long and complicated forum posting, maybe a data entry form in Formulize. Now imagine that they spend more than 24 minutes sitting in front of the form typing (or maybe even not that long, but they got up in the middle to go to the bathroom, get a coffee, whatever).

So after 24 minutes goes by, their session is now vulnerable to being killed by the garbage collector, even though the custom session expiry time is 60 minutes. After 24 minutes, there is a 1 in 100 chance (according to the default settings) that each page load on the server will trigger the garbage collector, which will kill all sessions older than 24 minutes (again, according to the default setting).

So suppose that this user has their session killed by the garbage collector, then when they submit the form, they are told that they are logged out and/or don't have permission for the page they are viewing, their information from the form is not saved and they are booted back to the login screen.

Not a nice user experience!

I suggest that the garbage collection function be modified so that it checks whether a custom session name and expiry time is in effect, and if so, then that time is used by the garbage collection routine instead. Something like this:



Any thoughts? Thanks very much,

--Julian

P.S. My session was killed while I was writing this (ironically enough!). Fortunately, clicking Back in Firefox remembers what I typed. If I were using IE, I might be totally screwed, if this page were generated by a $_POST request.

Which XOOPS version?

At least in 2.0.14 present:

Line 154 in xoops-2.0.14\htdocs\kernel\session.php

Please remember to submit this to the bug report on Sourceforge.

Thanks

Will do. I wanted to post here first to see if anyone had any comments or insights about session garbage collection that I had overlooked which might explain away the issue.

FYI: the sourceforge entry is here:
http://sourceforge.net/tracker/?func=detail&aid=1520134&group_id=41586&atid=430840

Some further debugging on our sites has confirmed that session.gc_maxlifetime from the php.ini is indeed used by the XOOPS session garbage collector even when custom session expiry times are in effect. So I think the original post is accurate.

With the exception that the suggested code change needs to be "times 60 seconds" since the custom expiry time that can be set by webmasters is in minutes.

re: which version...I believe this code has been unchanged since at least version 2.0.7.

--Julian

You're right in your analysis, now this is not a "bug", it's normal behavior. What you're pointing is that it's a nonsense to have gc_maxlifetime smaller than session_expire.

Now the fact the custom session settings allow you to customize session_expire, but not gc_maxlifetime is a problem.

1) It's been temporarily solved in 2.0.14 (in common.php, line 245, gc_maxlifetime is forced so it's equal to session_expire)
2) It's been completely handled in the 2.3 branch, where the session preferences panel gives you the possibility to change a lot more settings than before (like gc_maxlifetime, gc_probability...)

skalpa.>

Quote:

A-ha! I see that:

@ini_set('session.gc_maxlifetime', $xoopsConfig['session_expire'] * 60);

I was wondering if there was a way to force an override of the ini setting from within the code, but didn't know the right function. Thanks! We'll add this into the affected sites (or upgrade them to 2.0.14 soon).

--Julian