in reply to Cleaning up sessions created by Apache::Session::File when logging out of a CGI application

The problem is not with your code, it is that Apache::Session::File does not work in Taint mode.

The problem is that the session ID is stored along with the session itself. When you go to delete the session, it first loads the session from disk and unserializes it. This overwrites the session ID you passed it with the one it found in the file (they are both identical so it shouldn't matter). The problem is, the session ID is now tainted.

A quick fix for this is for you to untaint the session ID yourself after the session has been unserialized. Put the following two lines after you tie the session:

$session{_session_id} =~ /^([a-zA-Z0-9]+)$/;
$session{_session_id} = $1;

[download]

This probably should be fixed in Apache::Session itself as I am sure other people will run into it.

By the way, you really shouldn't be using Apache::Session::File anyway for performance reasons. At least use Apache::Session::DB_File which most likely doesn't suffer from this taint problem and will be much quicker.

  • Comment on Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
  • Select or Download Code

Replies are listed 'Best First'.
Re: Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
by Joey The Saint (Novice) on Feb 09, 2003 at 18:30 UTC

    Thanks, that did the trick. Well, sort of. My session files are getting cleaned up alright and I am probably going to move to a DB_File interface anyway, but when I delete the session, my lock files aren't being cleaned up as well. I thought I could work around this by adding these lines to the top of my script:

    my $l = new Apache::Session::Lock::File;
$l->clean('./.lockDir', 20);

    [download]

    Just above the lines:

    my $scriptName = $query->self_url;
$scriptName =~ s/\?.*//;

    [download]

    The problem is, my page where I do the logout modifies the lock, so no matter what it hasn't timed out when we get to the logout processing code, but when I come back into the script later, there are lock files that are hours old and they don't seem to get cleaned up either. I've read the documentation at http://search.cpan.org/author/JBAKER/Apache-Session-1.54/Session/Lock/File.pm and http://search.cpan.org/author/JBAKER/Apache-Session-1.54/Session/File.pm but I guess I still don't understand how the locking mechanism is supposed to work because I'm obviously using it incorrectly. Should I have an external script, maybe a cron job, that cleans up stale lock files? Figuring out which locks belong to sessions that no longer exist in the session directory wouldn't be hard, but I'd really rather understand the proper usage.

    Thanks again.

    -J.

[reply]
[d/l]
[select]

      Well, if you look carefully at the code for the clean method, you will see that it has a bug as well... The culprit is on line 136 of Apache::Session::Lock::File:

      if ((stat($dir.'/'.$file))[8] >= $time) - $now {

      This says: take the last access time of the lock file, subtract the current time and see if it is bigger than the proposed timelimit ($time). Since the current time will always be bigger than the last accees time, this number will always be negative. So unless you provided a negative timelimit to the clean function, the condition for deletion will never be met. Reversing the subtraction should fix the problem.

      if ($now - (stat($dir.'/'.$file))[8] >= $time) {

      Or you could pass a negative time limit to the clean method, but that could break if this bug ever gets fixed and you upgrade.

      Now, again I will try to convince you to scrap the File based sessions and move to at least the DB_File based one.

[reply]
[d/l]
[select]

        Thanks, I'd tried passing a negative value to the time limit as a last act of desperation before posting that, but it didn't seem to help, though I suspect -1 wasn't adequate for the task.

        And don't worry, I'm already convinced to use the DB_File approach. I'd really rather not introduce a dependency on something like MySQL, but DB_File shouldn't be a problem. The only reason I asked about the lock files is that Apache::Session::DB_File also takes a LockDirectory value in the same way ::File does, so I anticipated I'd have the same problem. Next time I'll try it before posting, though.

        -J.

[reply]

In Section Seekers of Perl Wisdom