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