The session expiration code in TWiki::Client::expireDeadSessions() says:
open(F, $file) || next;
my $session = <F>;
close F;
However, session files may contain newlines in string variables; this can be easily confirmed by inspecting the session files or with
wc -l
. That means this code won't work and sessions won't be expired correctly. More generally, it seems better to expire sessions that have errors upon read, instead of skipping them (i.e. leaving them around forever), as the current code does.
Well spotted!
Yes, it would be better to expire erroneous sessions. I guess they got left there to assist the debug process.
I realised that the repported issue with session evaluationwas in fact a red herring; the code had been hacked so that no non-zero session file passed the first condition.
So I rewrote the code more sensibly and safely.
Patch candidate?
CC
After another round of good discussion Crawford and I agreed that the best solution is never to read the session files at all in connection with expiry.
We do not have any feature where the expiry of the cookie file is not equal to the mtime (modification time) of the file + the expiry setting from configure.
So we can expire the cookies entirely from the timestamp that the OS gives and perl gives us vis stat.
The CGI::Session module writes to the session file each time we access any topic with a browser. Inside the cookie access time and expiry time is set. So this also resets the modification time to now. And we can take advantage of this.
So I have checked in a very simple replacement of the old function that does this.
It is much faster!
And much safer because we no longer read anything from the session file except through CGI::Session where security is handled much better than we can ever do in our own code.
--
KennethLavrsen - 31 Jan 2007
Also merged to Patch04x01 so fix is in 4.1.1
--
TWiki:Main.KennethLavrsen - 31 Jan 2007
Cleaned "WaitingFor" field.
--
TWiki:Main.GilmarSantosJr - 10 Aug 2008