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 )