getting index_html instead of manage_main in some browsers
Hello, In certain browsers (OmniWeb for MacOS X and a version of IE on Windows 2000), the management screen operates incorrectly. In the main frame of the management screen, manage_workspace returns the contents of index_html instead of manage_main. If for instance, if I view http://myzopesite/manage_workspace, I am redirected to http://myzopesite/index_html rather than the correct http://myzopesite/manage_main. I've only encountered this error with OmniWeb and whatever version of IE was on a Windows 2000 machine I was using in one of my university's research labs. When I first encountered the problem, I thought it was an error with my Zope installation, but the management screen works on every other browser I've encountered except these two. Is the problem with the browser or is it something that Zope is doing? Anyone ever seen this before? BTW, I've had this problem with both 2.3.3 (running on Linux) and 2.4b (running on MacOS X Server). Thanks. -- Mark James Adams mark@raysend.com
On Mon, 25 Jun 2001, Mark James Adams wrote:
In certain browsers (OmniWeb for MacOS X and a version of IE on Windows 2000), the management screen operates incorrectly. In the main frame of the management screen, manage_workspace returns the contents of index_html instead of manage_main.
Is the problem with the browser or is it something that Zope is doing? Anyone ever seen this before?
Some (but not all) builds of Mozilla (Linux) do the same. I think it is buggy browser problem. Well, all browsers are buggy... Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
It's a browser problem, but I'm not sure if we are relying on historical browser behavior or if these browsers actually break the spec. I'd be interested in knowing what the spec actually says about this. The problem is, Zope challenges you when you log into /manage. The browser pops up the auth box. You log in, and your browser successfully retrieves the frameset. Since the left frame *requires* authentication, it challenges the browser which send the credentials. The right frame does not require authentication, and in fact, will *not* challenge the browser. Zope assumes that the browser will automatically send the previously established credentials for the right frame, as all browsers do except the two you mention. You get index_html because Zope calculates which views you have permission to see on the object. Since it mistakenly assumes the right frame is "anonymous" (because the browser didn't send the credentials) you see the only thing that anonymous can see, index_html. So, the question is, does the spec define this behavior? Are browsers required to send authentication information previously established for a given realm even when *not* challenged by the server? Good question. Any HTTP wizards out there? -Michel On Mon, 25 Jun 2001, Mark James Adams wrote:
Hello,
In certain browsers (OmniWeb for MacOS X and a version of IE on Windows 2000), the management screen operates incorrectly. In the main frame of the management screen, manage_workspace returns the contents of index_html instead of manage_main.
If for instance, if I view http://myzopesite/manage_workspace, I am redirected to http://myzopesite/index_html rather than the correct http://myzopesite/manage_main.
I've only encountered this error with OmniWeb and whatever version of IE was on a Windows 2000 machine I was using in one of my university's research labs.
When I first encountered the problem, I thought it was an error with my Zope installation, but the management screen works on every other browser I've encountered except these two.
Is the problem with the browser or is it something that Zope is doing? Anyone ever seen this before?
BTW, I've had this problem with both 2.3.3 (running on Linux) and 2.4b (running on MacOS X Server).
Thanks.
-- Mark James Adams mark@raysend.com
_______________________________________________ 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 )
The problem is, Zope challenges you when you log into /manage. The browser pops up the auth box. You log in, and your browser successfully retrieves the frameset. Since the left frame *requires* authentication, it challenges the browser which send the credentials. The right frame does not require authentication, and in fact, will *not* challenge the browser. Zope assumes that the browser will automatically send the previously established credentials for the right frame, as all browsers do except the two you mention.
So, the question is, does the spec define this behavior? Are browsers required to send authentication information previously established for a given realm even when *not* challenged by the server?
The relevant RFC's are: HTTP/1.1: http://www.ietf.org/rfc/rfc2616.txt HTTP Authentication: Basic and Digest Access Authentication: http://www.ietf.org/rfc/rfc2617.txt RFC-2617 says in section 2 "Basic Authentication Scheme": A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. It says MAY, not MUST, not even SHOULD. I could not find any other part of the standard that suggests otherwise. So if I understand it correctly, Zope is relying on browser behaviour that is not required by the standard. That would mean the problem is caused by Zope, not by some browsers. Regards, Rene Pijlman
Exactly. And in fact I've had to make special "arrangements" (read: kludge) to support Basic Auth in my Zope application. My app runs in anonymous mode, and I had the login page somewhere in the directory hierarchy. Well, that was fine, except that Mozilla won't send the credentials for any page ABOVE the login page in the hierarchy (unless it is specifically marked as needing authentication). As a result, I would lose any personalized content for pages higher in the hierarchy. I had to put the login page at the top of the hierarchy and redirect to where I was going in the first place. Regards, -scott Rene Pijlman wrote:
The relevant RFC's are:
HTTP/1.1: http://www.ietf.org/rfc/rfc2616.txt
HTTP Authentication: Basic and Digest Access Authentication: http://www.ietf.org/rfc/rfc2617.txt
RFC-2617 says in section 2 "Basic Authentication Scheme":
A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.
It says MAY, not MUST, not even SHOULD. I could not find any other part of the standard that suggests otherwise.
So if I understand it correctly, Zope is relying on browser behaviour that is not required by the standard. That would mean the problem is caused by Zope, not by some browsers.
On Mon, 25 Jun 2001, Michel Pelletier wrote:
It's a browser problem, but I'm not sure if we are relying on historical browser behavior or if these browsers actually break the spec. I'd be interested in knowing what the spec actually says about this.
The problem is, Zope challenges you when you log into /manage. The browser pops up the auth box. You log in, and your browser successfully retrieves the frameset. Since the left frame *requires* authentication, it challenges the browser which send the credentials. The right frame does not require authentication, and in fact, will *not* challenge the browser. Zope assumes that the browser will automatically send the previously established credentials for the right frame, as all browsers do except the two you mention.
I observed this behaviour with w3m text mode browser and some latest builds of Mozilla. Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
mark> In certain browsers (OmniWeb for MacOS X and a version of IE on Windows mark> 2000), the management screen operates incorrectly. I've seen it on both OSX/OmniWeb and Win2k/IE5.blurf. The very strange part is that the occurances have stopped. We may have upgraded the IE5 machine (that's the common suggestion) however I have not changed the OSX setup! It was occuring when I was messing with authentication; at one point I had more than one acl_users on the site and one was set up for cookies and one wasn't. Don't know whether that's related or not. Jim Rowan DCSI jmr@computing.com
jim, this is actually related. the problem of getting index_html instead of manage_main should not happen in the case of cookie-based authentication, only using simple auth. the root of the problem is that some browsers will only send authentication info if they get explicitly asked for it and some will send it just because they have the information for the specific host. if it gets sent automatically zope will give you manage_main. if the browser does not send the information all by itself zope will not challenge it explicitly, it will simply send anything you're allowed to view without any auth info, meaning as anonymous. index_html is available for anonymous users. cookies on the other hand are always sent back to the server if they contain the same server name and path as the requested page. authentication cookies are not handled differently, to the browser they look like any other cookie. since, as you said, you still had the authentication cookie set it was sent along and was accepted as authentication, so you got manage_main. jens On Tuesday, June 26, 2001, at 01:52 , jmr@computing.com wrote:
mark> In certain browsers (OmniWeb for MacOS X and a version of IE on Windows mark> 2000), the management screen operates incorrectly.
I've seen it on both OSX/OmniWeb and Win2k/IE5.blurf. The very strange part is that the occurances have stopped. We may have upgraded the IE5 machine (that's the common suggestion) however I have not changed the OSX setup! It was occuring when I was messing with authentication; at one point I had more than one acl_users on the site and one was set up for cookies and one wasn't. Don't know whether that's related or not.
Jim Rowan DCSI jmr@computing.com
participants (7)
-
Jens Vagelpohl -
jmr＠computing.com -
Mark James Adams -
Michel Pelletier -
Oleg Broytmann -
Rene Pijlman -
Scott Anderson