[Zope] authentication problem
Jens Vagelpohl
jens@zope.com
Tue, 4 Sep 2001 07:51:40 -0400
my not was not meant to find some kind of scapegoat.
i am well aware that the behavior displayed by OmniWeb is within the spec,
and that's what i indicated in my emails to the OmniGroup staff. i asked
them to make OmniWeb's behavior "more closely aligned" with other browsers'
behavior.
jens
On Tuesday, September 4, 2001, at 07:15 , Richard Barrett wrote:
>
> 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 )
>