So I've been reading the source of LoginManager 0.8.8 for a while now and I'd love for someone to explain why what I'm about to say is crazy: There's some silliness going on in there with respect to handling presentation of the login form. Specifically: (1) findLogin of the BasicCookieLogin has an if which seems to be trying to use the loginForm DTML Document form values in the case that there is no cookie information about the user. Thus it seems the author intended for the loginForm to come up in response to any "unauthorized" access. The submission of that form would then "authorize" the user the second time around. I don't see how this would ever happen, though (see 2) (2) loginManager.py's lm_unath() functions, which replace response.unauthorized() when no user can be identified (such as in 1, when first accessing any page) both "append" the old() unauthorized() function to the loginForm DTML Document which they invoke. This old() seems to be the unauthorized() implementation found in HTMLResponse of Zope. What it does is to eventually raise an unauthorized exception, and this results in sending back a 401 w/ the WWW-Authenticate header that causes the panel to pop up for login. This prevents the loginForm DTML form from ever displaying. So what were the authors thinking here? Am I supposed to put a <dtml-try> in the standard document header and handle the unauthorized exception in some standard way in the footer? Just doesn't seem to make sense unless LoginManager was meant to be a top level user_folder and all this is left over or half-finished cruft. A. PS: This stuff needs to get an order of magnitude less painful to deal with, no?