[Zope] authentication problem
Richard Barrett
R.Barrett@ftel.co.uk
Tue, 04 Sep 2001 12:15:30 +0100
At 21:12 03/09/2001 -0400, Jens Vagelpohl wrote:
>this is a "known problem" with OmniWeb (and a few other browsers.
>
>OmniWeb will only send basic auth information when explicityly prompted.
>unfortunately, the page on the right-hand side of the ZMI
>(manage_workspace) does *not* prompt for authentication, it simply looks
>for the headers and if it cannot read them you get redirected to a
>"harmless" view, like index_html for the respective folder. most other
>browsers, once they have a username and password, automatically send that
>along for all other pages from the same webserver.
>
>i have sent feedback to the guys at OmniWeb twice so far, if you could add
>your voice to it that might help get it into production quicker.
>
>jens
I'm not familiar with OmniWeb but the relevant RFC2617 says:
"A client SHOULD assume that all paths at or deeper than the depth of the
last symbolic element in the path field of the Request-URI also are within
the protection space specified by the Basic realm value of the current
challenge. A client MAY preemptively send the corresponding Authorization
header with requests for resources in that space without receipt of another
challenge from the server."
My note: the client "MAY preemptively ...", not MUST.
So, while OmniWeb may be behaving differently to some other HTTP clients,
it appears to be behaving correctly. By the same token, Zope appears to be
wrong in not using a 401 Unauthorized response to ask for authentication
credentials as it should when some (repeat some) ZMI URLs are being
accessed, and authentication credentials are not presented with an initial
request.
If Zope did then challenge, citing the same realm, the client should then
respond with the credentials it has already obtained from the user for that
realm and not re-prompt the user for them. Zope's redirection to a
"harmless" view seems to be wrong in principle and practice.
This behaviour on Zope's part also explains why there are problems using
Windows IE5 to access the ZMI. This is not a fault with IE5 but a Zope
error. Typically the "manage_main" frame is not rendered correctly: the
same problem as you are finding with OmniWeb. (As a consequence, I normally
use Netscape for the ZMI and IE5 to view the site as a user.)
To illustrate the point, what follows is a summary of the main HTTP
requests and responses between a Windows IE5 client and a Zope server when
trying to access the ZMI. It turns out that like OmniWeb, IE5 does not
volunteer the authentication credentials but re-presents the request with
the credentials if the server issues a 401 challenge. However, for reasons
known only to Zope's authors, when the contents of the "manage_main" frame
are requested without credentials, Zope responds with a 302 Redirect rather
than demanding authorization with a 401 response.
--> C04 --> S05 ==== (41) Request <GET /DSL/manage HTTP/1.1>
<-- C04 <-- S05 ==== (41) Response 401 to <GET /DSL/manage HTTP/1.1>
--> C04 --> S05 ==== (51) Request <GET /DSL/manage HTTP/1.1>
<-- C04 <-- S05 ==== (51) Response 200 to <GET /DSL/manage HTTP/1.1>
--> C04 --> S05 ==== (51) Request <GET /DSL/manage_top_frame HTTP/1.1>
<-- C04 <-- S05 ==== (51) Response 401 to <GET /DSL/manage_top_frame
HTTP/1.1>
--> C04 --> S05 ==== (51) Request <GET /DSL/manage_top_frame HTTP/1.1>
<-- C04 <-- S05 ==== (51) Response 200 to <GET /DSL/manage_top_frame
HTTP/1.1>
--> C06 --> S07 ==== (51) Request <GET /DSL/manage_menu HTTP/1.1>
<-- C06 <-- S07 ==== (51) Response 401 to <GET /DSL/manage_menu HTTP/1.1>
--> C06 --> S07 ==== (51) Request <GET /DSL/manage_menu HTTP/1.1>
<-- C06 <-- S07 ==== (52) Response 200 to <GET /DSL/manage_menu HTTP/1.1>
--> C04 --> S05 ==== (51) Request <GET /DSL/manage_workspace HTTP/1.1>
<-- C04 <-- S05 ==== (52) Response 302 to <GET /DSL/manage_workspace
HTTP/1.1>
--> C04 --> S05 ==== (52) Request <GET /DSL/index_html HTTP/1.1>
<-- C04 <-- S05 ==== (52) Response 200 to <GET /DSL/index_html HTTP/1.1>
In the above IE5 did not prompt the user for the credentials each time, it
simply supplied those that it already had when the server asked for them.
This explains why Zope's default index_html contains the following
(erroneous) note:
"NOTE: Some versions of Microsoft Internet Explorer, (specifically IE 5.01
and early versions of IE 5.5) may have problems displaying Zope management
pages. If you cannot view the management pages, try upgrading your IE
installation to the latest release version, or use a different browser."
By contrast Netscape 4.7 includes the authentication credentials, if they
are available, with each initial request and the ZMI renders as expected.
Maybe it is time to patch Zope so that it is RFC standards conformant ??
>On Saturday, September 1, 2001, at 09:54 , Mitchell L Model wrote:
>
>>I would greatly appreciate it if people knowledgeable about the Zope user
>>authentication process would consider helping me with a problem even
>>though the context for the problem is extremely limited (Omniweb 10.0.5
>>on Mac OS X 10.0.4), because the answer will help me understand an
>>important part of Zope in addition to helping me get past my problem and
>>in fact, I think the answer probably has to do with the mechanism by
>>which web browsers communicate user authorization to server-side programs
>>generally, independent of Omniweb or Zope, so many people might find this
>>answer interesting.
>>
>>I couldn't use Zope at all on Omniweb before the just released version 10.
>>0.5, because although I could successfully connect to a specific port
>>included in the URL, Omniweb was not using that port for the frames
>>within the page. That seems to have been fixed with the newest version,
>>but I still have a problem: I can successfully log in to Zope, but all
>>attempts to use ZMI get redirected to View pages instead. I have traced
>>through the code in ZPublisher/BaseRequest.py and
>>ZServer/PubCore/ZServerPublisher.py to determine that the request's _auth
>>is coming in as None in Omniweb, but a more meaningful value in other
>>browsers. However, I'm having trouble finding where that information is
>>coming from (the indirections in the Python code make it tricky to catch
>>everything stepping through the code in pdb), and I've run out of time.
>>
>>I would GREATLY appreciate an explanation of where the authorization
>>information is coming from. I don't see the currently logged in user in
>>my CGI environment, including cookies. How does any server-side program
>>get the user authorization information from the browser after the user
>>has logged in and gone to a different frame or window?
>>--
>> --- Mitchell
>>
>>_______________________________________________
>>Zope maillist - Zope@zope.org
>>http://lists.zope.org/mailman/listinfo/zope
>>** No cross posts or HTML encoding! **
>>(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
>>http://lists.zope.org/mailman/listinfo/zope-dev )
>
>_______________________________________________
>Zope maillist - Zope@zope.org
>http://lists.zope.org/mailman/listinfo/zope
>** No cross posts or HTML encoding! **
>(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
>http://lists.zope.org/mailman/listinfo/zope-dev )