[albatross-users] Re: pre4 - Problems still ...

[Sheila King]

--On Monday, July 14, 2003 8:29 AM +1000 Dave Cole
<djc at object-craft.com.au> wrote:

>>>>>> "Sheila" == Sheila King <sheila at thinkspot.net> writes:
> 
> Sheila> --On Sunday, July 13, 2003 4:52 PM +1000 Dave Cole
> Sheila> <djc at object-craft.com.au> wrote:

> Sheila> Current Problem: Session Variables are still being lost, as
> Sheila> before. If you go to the initial log in page, it shows four
> Sheila> session variables, including _last_access and _authstatus but
> Sheila> when you go to the next page (after entering log in
> Sheila> information and attempting to authenticate) you go to the
> Sheila> Expired page (which is an error) and the two session variables
> Sheila> mentioned above are no longer in the session. The code
> Sheila> contains NO statements that remove the session or delete
> Sheila> session variables.

> The problem is a bit difficult to spot.  If you run ngrep you will see
> it though.
> 
> It looks like you have some <al-img> tags somewhere (haven't looked at
> the source yet) because I can see requests like this:
> 
>         GET http://mathxy.com/cgi-bin/test/mgr.py/spacer.gif
> 
> This is followed by a traceback response which you do not see because
> the browser thinks it should be getting an image.
> 
> After the traceback Albatross deletes the session, so you get dropped
> back to a session expired state.

OK, I've been working on this, and I do agree now that there is/are
error(s) in my code causing the session to drop.

I've installed Ethereal (<http://www.ethereal.com/>) and am trying to learn
how to use it to see the http response packets so that I can see these
errors you are mentioning.

There is definitely something different about the error handling in pre4 as
opposed to previous versions of Albatross.

The error you mention above is essentially a 404 error. There was no al-img
tag, but my commonmacros.html file did have a normal HTML <img> tag and the
image refereced was not on the server, and so should generate a 404 error.

However, it has apparently been like that for a long time (this image is
also called in my full application program) and has never caused session to
drop before.

Maybe it should cause session to drop. Dunno.

But, even if I fix that problem, there are other errors I've found, such as
expressions not being defined in the local context name space. Before these
always took me to the default Albatross error page (which I've not tried to
overwrite) with a nice traceback. When this happened, I KNEW that something
in my code was wrong.

Now it is not doing that. It is taking me to the expired session page in my
application and the only way I can see the tracebacks for anything (it
seems) is by sniffing packets.

I'm not a neophyte cgi programmer, although I'm no expert either. But I
have a fair/modest amount of experience in this area, and I've never had to
sniff packets before to read the error messages sent by a Python cgi script.

:(

Is this again something peculiar to the redirect/random URL type of
applications?

It looks to me like this new send_redirect function could be the culprit?
Or is at least involved in some way?

    def send_redirect(self, loc):
        cookie = self.get_header('Set-Cookie')
        if cookie:
            self.request.write_header('Set-Cookie', cookie)
        return self.request.redirect(loc) 

Could this be the reason that after the handle_exception method prints out
the traceback, that the request is still redirected to the previously
requested redirect page? If so, IMO this behavior should be modified.
handle_exception should print the output (traceback) and then halt.

I'm just grasping about to try and think why it is so flipping hard for me
to see that there are errors in my code, when with previous versions of
Albatross it was easy.

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