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
Mitchell L Model writes:
I can successfully log in to Zope, but all attempts to use ZMI get redirected to View pages instead. Seems that many browsers start with this problem in early versions.... Early IE 5 versions had the same problem (---> mailing list archives).
Lobby the Omniweb developpers to follow the HTTP recommendation to automatically send the Authorization header to any page below the folder for which an object called for special Authorization. Dieter
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 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 )
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 )
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 )
Richard Barrett wrote:
<snip>
My note: the client "MAY preemptively ...", not MUST. <snip> 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. This explains why Zope's default index_html contains the following (erroneous) note: <snip> "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." <snip>
Maybe it is time to patch Zope so that it is RFC standards conformant ??
This is probably the best summary I've read on this issue... cheers, Chris
I'm trying to install Zope on my Redhat machine right now from an RPM linked from the Zope site. It is claiming that I need python. I currently have python2.1 and it works just fine. I am normally a windows user, so I am not sure how to get the rpm to recognize that I already have the required dependencies. any help is certainly appreciated. Regards, J. Lake
On Tuesday, September 4, 2001, at 09:15 PM, Richard Barrett wrote:
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.
[...]
Maybe it is time to patch Zope so that it is RFC standards conformant ??
The only way I can see of doing this would be to make cookie based authentication the default, or to write a new HTTP RFC and get it accepted by all the browser maintainers out there. Note that the problem not only occurs in the management interface, but anywhere on your site that a page renders differently depending on if it is viewed by an Anonymous client or an authenticated client. It will probably only affect fringe dwellers (like myself - I will be buying Omniweb if this behaviour is changed) unless Microsoft decide to change IE's behaviour. The CoreSessionTracking product, when integrated into Zope core, might also provide an alternative if it could maintain session based on URL instead of cookies (can it do this now?). -- Stuart Bishop <zen@shangri-la.dropbear.id.au>
participants (7)
-
Chris Withers -
Dieter Maurer -
Jens Vagelpohl -
Jerry Lake -
Mitchell L Model -
Richard Barrett -
Stuart Bishop