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?