[albatross-users] Duplicate Cookies after unhandled exception in Random SessionFile

[Sheila King]

Hello again everybodeeee,

I wanted to share a phenomenon that I have experienced repeatedly, and am 
able to reproduce, in the event that this is something that needs looking 
into....

This is a situation that I first became aware of when trying to debug all 
the problems I was having after I initially upgraded to 1.10.
(See my previous whining at
http://www.object-craft.com.au/pipermail/albatross-users/2003-July/000746.h
tml
and here
http://www.object-craft.com.au/pipermail/albatross-users/2003-July/000728.h
tml
etc...)

After extensive testing, I found out what was causing the problem, and why 
I was unable to see it and therefore assumed that Albatross was simply 
losing session variables.

What was actually happening in that case (noted above) is this:

(1) I finally narrowed my problem down to a particular page (module) in my 
app that was consistently creating this error, where other pages were fine.
(2) This particular page had an incorrect relative path to an image file, 
resulting in a 404 for that image. The rest of the page was fine, except 
for that image.
(3) Albatross would, as a result, try to run the Bad URL function, however, 
I had  overridden the default Bad URL function with one of my own. Problem 
was, there was an error in that, as well. In my load_badurl_template(), 
there was a call to load an html template badurl.html that tried to use a 
local variable in the template, where the local variable had not been set 
already.
(4) As what occurred in (3) was an unhandled exception, as one would expect 
the session was removed. However, the cookie was not.
(5) Since there HAD been a valid, authenticated session, which was now no 
longer authenticated, this resulted in my app redirecting to the "expired 
session" page.
At this point, there were two copies of the same, cookie from the previous 
session, with the session variables removed.

It was only possible to figure out all of the above by sniffing packets, as 
it all happened so fast, I would just see it go right to the expired 
session page each time.

(6) Now here is the kicker...
The original session cookie did not get removed, but the session vars did, 
then in (5) the cookie got duplicated and there were TWO cookies with the 
exact same session ID. UPON TRYING TO RE-LOG IN what would happen is that a 
new cookie would be created, but one of the old cookies would still be 
there, resulting in two stored cookies for my app ID. That "bad" cookie 
would never leave, and I would never be able to establish another valid 
session unless I went into the browser preferences and edited (deleted) the 
cookies from my browser manually.

Now, it seems to me that upon an unhandled exception, that the cookie 
should be removed too? At least, I never had this problem in 1.01 (I know, 
that does not necessarily mean anything). But something about random app 
redirects did change in 1.10 and I'm just wondering if this cookie-thing 
has been overlooked?

I didn't mention this before for several reasons, not the least of which 
are I've been too busy to sit down and type this all up, and also I figured 
it was my fault anyhow, since I DID have boo-boos in my application. Two 
cascading boo-boos that managed to hide from me what was actually going on.

However, in the meantime I had applied Matt Goodall's cookie path patch for 
session.py and sessionfile.py and thought that maybe I would not see this 
problem again.

But it occurred again today, and not where I have cascading errors, and I 
did get the traceback for the unhandled exception displayed to the browser. 
But what happens now, is when I got to the login page to try and log in 
again, I get two cookies and am unable to establish a valid session without 
going into my browser preferences and manually deleting the cookies.

OK, well, just sharing in case this is something that someone might want to 
look into...

-- 
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org