1
jegelstaff
Session garbage collection bug when using custom sessions

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:

function gc($expire)
{
  
$mintime time() - intval($expire);
  
$sql sprintf('DELETE FROM %s WHERE sess_updated < %u'$this->db->prefix('session'), $mintime);
  return 
$this->db->queryF($sql);
}


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:

function gc($expire)
{
  global 
$xoopsConfig;
  
$expire = ($xoopsConfig['use_mysession'] && $xoopsConfig['session_name'] != '') ? $xoopsConfig['session_expire'] : $expire;
  
$mintime time() - intval($expire);
  
$sql sprintf('DELETE FROM %s WHERE sess_updated < %u'$this->db->prefix('session'), $mintime);
  return 
$this->db->queryF($sql);
}


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.
Technical Architect - Freeform Solutions
Formulize - custom registration forms, ad hoc forms and reports

2
rowdie
Re: Session garbage collection bug when using custom sessions
  • 2006/7/10 17:29

  • rowdie

  • Just can't stay away

  • Posts: 846

  • Since: 2004/7/21


Which XOOPS version?

3
Bender
Re: Session garbage collection bug when using custom sessions
  • 2006/7/10 17:47

  • Bender

  • Home away from home

  • Posts: 1899

  • Since: 2003/3/10


At least in 2.0.14 present:

Line 154 in xoops-2.0.14\htdocs\kernel\session.php
Sorry, this signature is experiencing technical difficulties. We will return you to the sheduled signature as soon as possible ...

4
davidl2
Re: Session garbage collection bug when using custom sessions
  • 2006/7/10 17:56

  • davidl2

  • XOOPS is my life!

  • Posts: 4843

  • Since: 2003/5/26


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

Thanks

5
jegelstaff
Re: Session garbage collection bug when using custom sessions

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= ... roup_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
Technical Architect - Freeform Solutions
Formulize - custom registration forms, ad hoc forms and reports

6
skalpa
Re: Session garbage collection bug when using custom sessions
  • 2006/7/10 18:44

  • skalpa

  • Quite a regular

  • Posts: 300

  • Since: 2003/4/16


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.>
Any intelligent fool can make things bigger, and more complex. It takes a touch of genius, a lot of courage, to move in the opposite direction.
Two things are infinite: the universe and human stupidity; and I'm not sure about the 1st one (A.Einstein)

7
jegelstaff
Re: Session garbage collection bug when using custom sessions

Quote:

skalpa wrote:
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)


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
Technical Architect - Freeform Solutions
Formulize - custom registration forms, ad hoc forms and reports

Login

Who's Online

100 user(s) are online (56 user(s) are browsing Support Forums)


Members: 0


Guests: 100


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Aug 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits