[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 )
>