[Zope] Re: CoreSessionTracking

[Chris McDonough]

Uwe,

I misunderstood the context in which you were using the dtml method.  I
thought it was a dtml method which was outside of a LoginManager
instance but which called a LoginManager instance somehow.  Sorry.

>From your latest description, it seems that my transaction theory might
be wrong. It wouldn't really matter if the raise happened later. As long
as the commit happens directly after the set, the session data should
show up in any subsequent access.  Zope has implicit transaction
boundaries where the beginning of a request starts a ZODB transaction
and the beginning of a response commits it.  Explicitly committing a
transaction like this just causes the ZODB to begin a new transaction
during the processing of the request, so this is the series of events
that probably happens when you use the dtml form with the commit_trans
thingy in it:

request starts
transaction 1 begins
session data is set
transaction 1 is committed (session data is stored)
transaction 2 begins
dtml-raise happens
transaction 2 is aborted due to the raise
response is sent

I'm not completely sure of this because I don't know how loginmanager
treats a "raise LoginRequired", but if it treats it anything like Zope
treats "raise Unauthorized", it means that stuff done in the transaction
immediately prior to the raise is lost, and a new transaction starts.

Let me try to understand this better (and sorry if these sound like dumb
questions).  You want an unauthorized exception to be caught by
something that examines the session data and determines if there's a
key/value pair in the session data object that matches something.  If
so, let the user in.  If not, cause a web form to be shown asking for
authentication.  What value is in the request that you're trying to
compare against the session data to do authentication?  A cookie value? 

- C





"Uwe C. Schroeder" wrote:

> Ok, I did this - no effect. But I tried to use a normal dtml-method with the
> form on it and the same session related code. That works. So it isn't a
> general problem of my installation or the session management. It must have
> something to do with the login manager stuff. I'll dig into login manager and
> see how things work there. I think the guess about the raise might be quite
> good. When I remove the raise from the login manager method the method won't
> get called at all - instead the normal "basic auth" window appears. So my bet
> is that there is another raise with something like "auth required" inside the
> login manager methods. I'll check that. Probably only the placement of the
> commit is wrong.
> 
> Thanks for your help