WebGUI
      Click here to register.
      
Sprechen Sie WebGUI? Parlez vous WebGUI? Se habla WebGUI? Spreekt u WebGUI?

Do you speak WebGUI? Please help us translate WebGUI into your language.



     Report a Bug > WebGUI Bug Tracker

Expired SessionScratch not deleted

User mlamar
Date 11/1/2007 12:35 pm
Severity Minor (annoying, but not harmful)
Version WebGUI 7.3.22 (and beyond)
Views 113
Rating 1    Rate [
|
]
Karma Rank 0.000000
Previous · Next
User Message
mlamar

When a session is expired by the workflow activity DeleteExpiredSessions, the userSessionScratch variables associated with that session are not removed from the database.  Since session ids are stored as cookies on a user's computer, the next time a user on that computer (& browser) comes to the site, they get a new session with the same id.  They then "inherit" the scratch variables from the possibly quite old session.  For operations and wobjects that depend on the scratch variables this can cause bizzare behaviors.

The problem is with the "noFuss" parameter that DeleteExpiredSessions passes into WebGUI::Session->open.  In the current implementation (including 7.4.12), the "noFuss" parameter causes the session to be returned before $session->{_sessionId} is set.  So later in Session::Scratch when it tries to delete scratch that matches $session->sessionId it is trying to match an empty value. 

NOTE: This may be causing other problems if "noFuss" is used in other contexts. 

I have included a patch file.  The fix is in Var.pm:

*** Var.pm.orig 2007-11-01 09:25:14.000000000 -0700
--- Var.pm      2007-11-01 10:17:14.000000000 -0700
***************
*** 175,181 ****
                $self->start(1);
        } else { ##existing session requested
                $self->{_var} = $session->db->quickHashRef("select * from userSession where sessionId=?",[$sessionId]);
!               return $self if $noFuss && $self->{_var}{sessionId};
                if ($self->{_var}{expires} && $self->{_var}{expires} < $session->datetime->time()) { ##Session expired, start a new one with the same Id
                        $self->end;
                        $self->start(1,$sessionId);
--- 175,184 ----
                $self->start(1);
        } else { ##existing session requested
                $self->{_var} = $session->db->quickHashRef("select * from userSession where sessionId=?",[$sessionId]);
!               if($noFuss && $self->{_var}{sessionId}) {
!                   $self->session->{_sessionId} = $self->{_var}{sessionId};
!                   return $self;
!               }
                if ($self->{_var}{expires} && $self->{_var}{expires} < $session->datetime->time()) { ##Session expired, start a new one with the same Id
                        $self->end;
                        $self->start(1,$sessionId);
 

 



Attached Files
Back to Top
Rate [
|
]
 
 
colink

I agree that this is a bug, but don't you think it's also a bug that userSessionScratch never gets cleaned up either?

Maybe it should be a separately filed bug.

(Never mind.  $session->var->end calls $session->scratch->deleteAll anyway).

I'll write a test to verify the bug, then apply your patch and commit it. 



Back to Top
Rate [
|
]
 
 
xootom

Is this related to the bug I filed since 7.4.11 that expired user sessions themselves aren't clearing?

http://www.plainblack.com/bugs/tracker/expired-user-sessions-not-clearing

If you look in your Admin/Active Sessions can you see sessions going back to about 25 October?



Back to Top
Rate [
|
]
 
 
mlamar

Yes, var->end calls scratch->deleteAll, and it's in that call that the inproperly set sessionId causes the delete to fail.

No, I don't think this is the same as the sessions not expiring bug, because in my case I see the sessions expire, they just leave behind their scratch variables. 



Back to Top
Rate [
|
]
 
 
colink

Fixed in 7.4.13

Thanks for the patch and bug, Michelle! 



Back to Top
Rate [
|
]