[Zope] LoginManager Mania
Andrew Athan
aathan-zope-list%REMOVEME@memeplex.com
Fri, 6 Apr 2001 06:12:24 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_00CD_01C0BE60.8C2E0D20
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
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?
------=_NextPart_000_00CD_01C0BE60.8C2E0D20
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial size=3D2>So =
I've been reading=20
the source of LoginManager 0.8.8 for a while now and I'd love for =
someone to=20
explain why what I'm about to say is crazy: There's some silliness =
going=20
on in there with respect to handling presentation of the login=20
form.</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2>Specifically:</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial size=3D2>(1) =
findLogin of the=20
BasicCookieLogin has an if which seems to be trying to use the loginForm =
DTML=20
Document form values in the case that there is no cookie =
information about=20
the user. Thus it seems the author intended for the loginForm to =
come up=20
in response to any "unauthorized" access. The submission of that =
form=20
would then "authorize" the user the second time around. I don't =
see how=20
this would ever happen, though (see 2)</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial size=3D2>(2)=20
loginManager.py's lm_unath() functions, which replace =
response.unauthorized()=20
when no user can be identified (such as in 1, when first accessing any =
page)=20
both "append" the old() unauthorized() function to the loginForm DTML =
Document=20
which they invoke. This old() seems to be the unauthorized()=20
implementation found in HTMLResponse of Zope. What it does is to=20
eventually raise an unauthorized exception, and this results in sending =
back a=20
401 w/ the WWW-Authenticate header that causes the panel to pop up for=20
login. This prevents the loginForm DTML form from ever=20
displaying.</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial size=3D2>So =
what were the=20
authors thinking here? Am I supposed to put a <dtml-try> in =
the=20
standard document header and handle the unauthorized exception in some =
standard=20
way in the footer? Just doesn't seem to make sense unless =
LoginManager was=20
meant to be a top level user_folder and all this is left over or =
half-finished=20
cruft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2>A.</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D674164509-06042001><FONT face=3DArial =
size=3D2>PS: This stuff=20
needs to get an order of magnitude less painful to deal with,=20
no?</FONT></SPAN></DIV>
<DIV><SPAN class=3D674164509-06042001></SPAN> </DIV></BODY></HTML>
------=_NextPart_000_00CD_01C0BE60.8C2E0D20--