I have a problem that I have struggled with off and on for weeks without success. Goal: Serve files (mainly msword and excel) with authentication, to Microsoft/IE users supporting the ability to logout, without forcing the user to reauthenticate multiple times. Approach: To support the ability to log out, most reading I've found pointed me to CookieCrumbler, which I'm using. Problem: IE on windows appears to want to use WebDAV, which doesn't understand cookies AFAIK and thus tries to reauthenticate using basic http authentication Proposed Solution: Use the webdav source port, eg 1980. Gripe: I have no trouble with any tested browser / OS combination other than Microsoft Windows with IE. 99% of my users will be on this combination, however. Before I launch into a bunch of techo mumbo jumbo below, I am open to alternative solutions. If there is a better way to do this let me know. It seems to me that it shouldn't be impossible to gracefully serve protected files to Microsoft users while supporting logouts, but maybe it is. In particular, I have no interest in supporting webdav, but as far as I understand, I cannot disable this on server side (if I can, please tell me!!). So a lot of stuff below is targeted at getting webdav to work with cookie crumbler. If I can't figure this out, I'll have to jettison cookie crumbler and logouts. I have created a sandbox at http://crcdocs.bsd.uchicago.edu/test. This area has default permissions, except for the following, which require authenticated|manager|owner privs View Access Contents information Manage WebDAV locks WebDAV Lock items WebDAV Unlock items WebDAV access There are two acl_users 'test' and 'testman'. Both have password '123'. The latter has manager permissions. The 'test' directory has a single msword file 'facepage.doc', and an index_html method that serves this file either over 80 or 1980. I am using a default instantiation of CookieCrumbler 1.2 in that dir. I have the following in my zope.conf to enable webdav <webdav-source-server> # valid keys are "address" and "force-connection-close" address 1980 force-connection-close off </webdav-source-server> When the user clicks on either the port 80 link or the port 1980 link in index_html, even though they've already cookie authenticated when initially loading index_html, they get a basic http authentication dialog. Is there some special trick to serve files over the webdav source port? Perhaps I'm naive in thinking all I need to do is add the above lines to zope.conf, restart zope, and then serve the file over 1980. I installed VerboseSecurity-0.6. When the user clicks on the 1980 link, they are presented with the authentication challenge box 2 times and then can read the file. Subsequent attempts to access the file are successful without additional authentication challenges. 4 error log entries are created during the initial attempt to access the document, summarized in order here. 1st error Time 2004/09/25 12:21:51.553 GMT-5 User Name (User Id) Anonymous User (None) Request URL http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/manage_DAVget Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. 2nd error Time 2004/09/25 12:21:55.570 GMT-5 User Name (User Id) Anonymous User (None) Request URL http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/LOCK Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. 3rd error Time 2004/09/25 12:21:57.156 GMT-5 User Name (User Id) Anonymous User (None) Request URL http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/LOCK Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. 4th error Time 2004/09/25 12:21:57.177 GMT-5 User Name (User Id) test (test) Request URL http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/LOCK Exception Type RuntimeError Exception Value Syntax error at line 9: illegal character in content Included below is the full traceback and REQUEST header from the first error. Please feel free to log to http://crcdocs.bsd.uchicago.edu/test as user 'test' or 'testman' if you are kind enough to help me solve this vexing problem. JDH - Zope 2.7 Exception traceback Time 2004/09/25 12:21:51.553 GMT-5 User Name (User Id) Anonymous User (None) Request URL http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/manage_DAVget Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. Traceback (innermost last): * Module ZPublisher.Publish, line 92, in publish * Module ZPublisher.BaseRequest, line 439, in traverse * Module ZPublisher.HTTPResponse, line 671, in unauthorized Unauthorized: <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. Display traceback as text REQUEST form cookies SITESERVER 'ID=38c1d83c249f02a07f0d04cbbf5f1ee5' __ac 'dGVzdDoxMjM%3D' __ac_name 'test' lazy items SESSION <bound method SessionDataManager.getSessionData of <SessionDataManager instance at 2a9bd27350>> other TraversalRequestNameStack [] URL 'http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/manage_DAVget' SERVER_URL 'http://crcdocs.bsd.uchicago.edu:1980' PUBLISHED <bound method File.manage_DAVget of <File instance at 2a9bd7ecb0>> URL0 http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/manage_DAVget URL1 http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc URL2 http://crcdocs.bsd.uchicago.edu:1980/test URL3 http://crcdocs.bsd.uchicago.edu:1980 BASE0 http://crcdocs.bsd.uchicago.edu:1980 BASE1 http://crcdocs.bsd.uchicago.edu:1980 BASE2 http://crcdocs.bsd.uchicago.edu:1980/test BASE3 http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc BASE4 http://crcdocs.bsd.uchicago.edu:1980/test/facepage.doc/manage_DAVget environ HTTP_ACCEPT 'application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*' CONNECTION_TYPE 'Keep-Alive' HTTP_USER_AGENT 'Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)' HTTP_REFERER 'http://crcdocs.bsd.uchicago.edu/test/index_html' SERVER_NAME 'localhost.localdomain' GATEWAY_INTERFACE 'CGI/1.1' SERVER_SOFTWARE 'Zope/(unreleased version, python 2.3.4, linux2) ZServer/1.1' REMOTE_ADDR '24.14.147.78' HTTP_ACCEPT_LANGUAGE 'en-us' SCRIPT_NAME '' REQUEST_METHOD 'GET'
"John" == John Hunter <jdhunter@ace.bsd.uchicago.edu> writes:
John> Problem: IE on windows appears to want to use WebDAV, which John> doesn't understand cookies AFAIK and thus tries to John> reauthenticate using basic http authentication Hmm, it appears that the cause of my problems lie elsewhere. In an attempt to debug and simplify this problem, I did a clean install of python 2.3.4 and zope 2.7.2 on a new server, default configs on everything accept the effective user, no cookie crumbler or any other add-on modules, and I found the same problem with basic authentication. A friend tried accessing the same resource (different win32/IE combination) and had no troubles. It looks like a bug specific to my OS or browser (Win98 with IE6, all service packs up-to-date). Attached below is the error log generated when I try and access the doc file with my browser. Basically, IE is making an "Anonymous User" LOCK request, even though it has already been authenticated with basic authentication for the dir the doc file lives in. I've also seen the same problem when IE tries to Request URL http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html (my msdoc with /index_html postpended). In both cases, the offending user agent is HTTP_USER_AGENT 'Microsoft Data Access Internet Publishing Provider DAV'. On my server with the same browser, I can readily access a wpd document in the same location with no superfluous authentication annoyances. Has anyone seen this before - any ideas on how to further diagnose or better yet, fix it? I've seen enough flaky behavior in the last few weeks regarding authentication on MS/IE -- only on MS Office docs -- on at least 5 different machines to know I can't ignore this one. Exception traceback Time 2004/09/25 16:48:21.291 GMT-4 User Name (User Id) Anonymous User (None) Request URL http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/LOCK Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. Traceback (innermost last): * Module ZPublisher.Publish, line 92, in publish * Module ZPublisher.BaseRequest, line 439, in traverse * Module ZPublisher.HTTPResponse, line 671, in unauthorized Unauthorized: <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. Display traceback as text Exception traceback Time 2004/09/25 17:02:41.515 GMT-4 User Name (User Id) Anonymous User (None) Request URL http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. Traceback (innermost last): * Module ZPublisher.Publish, line 92, in publish * Module ZPublisher.BaseRequest, line 439, in traverse * Module ZPublisher.HTTPResponse, line 671, in unauthorized Unauthorized: <strong>You are not authorized to access this resource.</strong><p> No Authorization header found. Display traceback as text REQUEST form cookies SITESERVER 'ID=38c1d83c249f02a07f0d04cbbf5f1ee5' lazy items SESSION <bound method SessionDataManager.getSessionData of <SessionDataManager instance at 2a9b780a30>> other TraversalRequestNameStack [] URL 'http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html' SERVER_URL 'http://crcdocs2.bsd.uchicago.edu:8080' PUBLISHED <bound method File.index_html of <File instance at 2a9b8f7490>> URL0 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html URL1 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc URL2 http://crcdocs2.bsd.uchicago.edu:8080/test URL3 http://crcdocs2.bsd.uchicago.edu:8080 BASE0 http://crcdocs2.bsd.uchicago.edu:8080 BASE1 http://crcdocs2.bsd.uchicago.edu:8080 BASE2 http://crcdocs2.bsd.uchicago.edu:8080/test BASE3 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc BASE4 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html environ CONNECTION_TYPE 'Keep-Alive' HTTP_TRANSLATE 'f' HTTP_USER_AGENT 'Microsoft Data Access Internet Publishing Provider DAV' HTTP_COOKIE 'SITESERVER=ID=38c1d83c249f02a07f0d04cbbf5f1ee5' SERVER_NAME 'crcdocs2.bsd.uchicago.edu' GATEWAY_INTERFACE 'CGI/1.1' SERVER_SOFTWARE 'Zope/(unreleased version, python 2.3.4, linux2) ZServer/1.1' REMOTE_ADDR '24.14.147.78' HTTP_ACCEPT_LANGUAGE 'en-us' SCRIPT_NAME '' REQUEST_METHOD 'GET' HTTP_HOST 'crcdocs2.bsd.uchicago.edu:8080' PATH_INFO '/test/research_plan.doc' SERVER_PORT '8080' SERVER_PROTOCOL 'HTTP/1.1' channel.creation_time 1096146116 PATH_TRANSLATED '/test/research_plan.doc'
Yup. Seen it. http://www.plope.com/Members/chrism/ms_befuddled/view Still haven't fixed it. Reportedly it has something to do with the headers that Zope sends in its requests. On Sat, 2004-09-25 at 16:22, John Hunter wrote:
"John" == John Hunter <jdhunter@ace.bsd.uchicago.edu> writes:
John> Problem: IE on windows appears to want to use WebDAV, which John> doesn't understand cookies AFAIK and thus tries to John> reauthenticate using basic http authentication
Hmm, it appears that the cause of my problems lie elsewhere. In an attempt to debug and simplify this problem, I did a clean install of python 2.3.4 and zope 2.7.2 on a new server, default configs on everything accept the effective user, no cookie crumbler or any other add-on modules, and I found the same problem with basic authentication. A friend tried accessing the same resource (different win32/IE combination) and had no troubles. It looks like a bug specific to my OS or browser (Win98 with IE6, all service packs up-to-date).
Attached below is the error log generated when I try and access the doc file with my browser. Basically, IE is making an "Anonymous User" LOCK request, even though it has already been authenticated with basic authentication for the dir the doc file lives in. I've also seen the same problem when IE tries to Request URL http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html (my msdoc with /index_html postpended). In both cases, the offending user agent is HTTP_USER_AGENT 'Microsoft Data Access Internet Publishing Provider DAV'. On my server with the same browser, I can readily access a wpd document in the same location with no superfluous authentication annoyances.
Has anyone seen this before - any ideas on how to further diagnose or better yet, fix it? I've seen enough flaky behavior in the last few weeks regarding authentication on MS/IE -- only on MS Office docs -- on at least 5 different machines to know I can't ignore this one.
Exception traceback
Time 2004/09/25 16:48:21.291 GMT-4 User Name (User Id) Anonymous User (None) Request URL http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/LOCK Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found.
Traceback (innermost last):
* Module ZPublisher.Publish, line 92, in publish * Module ZPublisher.BaseRequest, line 439, in traverse * Module ZPublisher.HTTPResponse, line 671, in unauthorized
Unauthorized: <strong>You are not authorized to access this resource.</strong><p> No Authorization header found.
Display traceback as text
Exception traceback
Time 2004/09/25 17:02:41.515 GMT-4 User Name (User Id) Anonymous User (None) Request URL http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html Exception Type Unauthorized Exception Value <strong>You are not authorized to access this resource.</strong><p> No Authorization header found.
Traceback (innermost last):
* Module ZPublisher.Publish, line 92, in publish * Module ZPublisher.BaseRequest, line 439, in traverse * Module ZPublisher.HTTPResponse, line 671, in unauthorized
Unauthorized: <strong>You are not authorized to access this resource.</strong><p> No Authorization header found.
Display traceback as text
REQUEST form cookies SITESERVER 'ID=38c1d83c249f02a07f0d04cbbf5f1ee5' lazy items SESSION <bound method SessionDataManager.getSessionData of <SessionDataManager instance at 2a9b780a30>> other TraversalRequestNameStack [] URL 'http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html' SERVER_URL 'http://crcdocs2.bsd.uchicago.edu:8080' PUBLISHED <bound method File.index_html of <File instance at 2a9b8f7490>> URL0 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html URL1 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc URL2 http://crcdocs2.bsd.uchicago.edu:8080/test URL3 http://crcdocs2.bsd.uchicago.edu:8080 BASE0 http://crcdocs2.bsd.uchicago.edu:8080 BASE1 http://crcdocs2.bsd.uchicago.edu:8080 BASE2 http://crcdocs2.bsd.uchicago.edu:8080/test BASE3 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc BASE4 http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html environ CONNECTION_TYPE 'Keep-Alive' HTTP_TRANSLATE 'f' HTTP_USER_AGENT 'Microsoft Data Access Internet Publishing Provider DAV' HTTP_COOKIE 'SITESERVER=ID=38c1d83c249f02a07f0d04cbbf5f1ee5' SERVER_NAME 'crcdocs2.bsd.uchicago.edu' GATEWAY_INTERFACE 'CGI/1.1' SERVER_SOFTWARE 'Zope/(unreleased version, python 2.3.4, linux2) ZServer/1.1' REMOTE_ADDR '24.14.147.78' HTTP_ACCEPT_LANGUAGE 'en-us' SCRIPT_NAME '' REQUEST_METHOD 'GET' HTTP_HOST 'crcdocs2.bsd.uchicago.edu:8080' PATH_INFO '/test/research_plan.doc' SERVER_PORT '8080' SERVER_PROTOCOL 'HTTP/1.1' channel.creation_time 1096146116 PATH_TRANSLATED '/test/research_plan.doc' _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
"Chris" == Chris McDonough <chrism@plope.com> writes:
Chris> Yup. Seen it. Chris> http://www.plope.com/Members/chrism/ms_befuddled/view Chris> Still haven't fixed it. Chris> Reportedly it has something to do with the headers that Chris> Zope sends in its requests. Oh you tease me so! I read you page and immediately grepped the zope srcs for MS-Author-Via and commented them all out (Resource.py and Collection.py), restarted zope and tried my link (with so much anticipation)... But to no avail. Still got the damn authentication box. Of course, as noted on your page I can right click save without issue. At the very least I can make it a FAQ and include a link to win32 Firefox on my site. I sure would like to get this fixed though. I wonder if the header stuff on your link is a red herring since it doesn't seem to help. JDH
On Sat, 2004-09-25 at 16:46, John Hunter wrote:
"Chris" == Chris McDonough <chrism@plope.com> writes:
Chris> Yup. Seen it. Chris> http://www.plope.com/Members/chrism/ms_befuddled/view
Chris> Still haven't fixed it.
Chris> Reportedly it has something to do with the headers that Chris> Zope sends in its requests.
Oh you tease me so!
Growl. ;-)
I read you page and immediately grepped the zope srcs for MS-Author-Via and commented them all out (Resource.py and Collection.py), restarted zope and tried my link (with so much anticipation)...
But to no avail. Still got the damn authentication box.
How about commenting "ETag" headers out too? Any joy?
Of course, as noted on your page I can right click save without issue. At the very least I can make it a FAQ and include a link to win32 Firefox on my site. I sure would like to get this fixed though.
Me too. I'm hoping someone else figures it out! ;-)
I wonder if the header stuff on your link is a red herring since it doesn't seem to help.
I don't know either... As evidenced on that page, I still don't quite grasp what IE is trying to do. - C
"Chris" == Chris McDonough <chrism@plope.com> writes:
Chris> How about commenting "ETag" headers out too? Any joy? I only found one place in the webdav subdir where etag headers were set and that was in Resource.py. Commenting that out, along with the MS-Author-Via header, did not help. JDH
Well, then it's still a mystery. Some binary exclusion in the code would need to take place to see just why IE thinks its a reasonable thing to ask for OPTIONS on that second request. :-( On Sun, 2004-09-26 at 12:35, John Hunter wrote:
"Chris" == Chris McDonough <chrism@plope.com> writes:
Chris> How about commenting "ETag" headers out too? Any joy?
I only found one place in the webdav subdir where etag headers were set and that was in Resource.py. Commenting that out, along with the MS-Author-Via header, did not help.
JDH
Chris/John: Have a read of this: http://zope.org/Collectors/Zope/1441 ...particularly Entry #3. You may even want to give 2.7.3b1 a go. If that fails, don't worry, I have some other ideas... Chris Chris McDonough wrote:
Well, then it's still a mystery. Some binary exclusion in the code would need to take place to see just why IE thinks its a reasonable thing to ask for OPTIONS on that second request. :-(
On Sun, 2004-09-26 at 12:35, John Hunter wrote:
>"Chris" == Chris McDonough <chrism@plope.com> writes:
Chris> How about commenting "ETag" headers out too? Any joy?
I only found one place in the webdav subdir where etag headers were set and that was in Resource.py. Commenting that out, along with the MS-Author-Via header, did not help.
JDH
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
"Chris" == Chris Withers <chris@simplistix.co.uk> writes:
Chris> Chris/John: Have a read of this: Chris> http://zope.org/Collectors/Zope/1441 Chris> ...particularly Entry #3. My take on this entry was to try commenting out the following headers (using 2.7.2) [zope@crcdocs webdav]$ grep -i setheader *.py |grep -i dav Collection.py: #response.setHeader('MS-Author-Via', 'DAV') Resource.py: #response.setHeader('MS-Author-Via', 'DAV') Resource.py: #RESPONSE.setHeader('DAV', '1,2', 1) Did this, restarted zope, still get the pesky dialog box with this in the error log URL 'http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html' HTTP_USER_AGENT 'Microsoft Data Access Internet Publishing Provider DAV' I also tried with and without the etag header. Chris> You may even want to give 2.7.3b1 a go. Tried it, no help. I noticed that all these headers were commented out by default in 2.7.3. The authentication dialog pops up even if the File object has anonymous view and access contents info IE 6.0.2800 Word 2000 Windows XP Chris> If that fails, don't worry, I have some other ideas... Fire away! JDH
John Hunter wrote at 2004-9-27 09:07 -0500:
... Did this, restarted zope, still get the pesky dialog box with this in the error log
URL 'http://crcdocs2.bsd.uchicago.edu:8080/test/research_plan.doc/index_html' HTTP_USER_AGENT 'Microsoft Data Access Internet Publishing Provider DAV'
Maybe, a configuration option for your IE (always try to use WebDAV)? -- Dieter
John Hunter wrote:
Tried it, no help. I noticed that all these headers were commented out by default in 2.7.3. The authentication dialog pops up even if the File object has anonymous view and access contents info
IE 6.0.2800 Word 2000 Windows XP
Chris> If that fails, don't worry, I have some other ideas...
Fire away!
Right, are you proxying through apache? If so, try inserting the following in the section handling your Zope (you'll need the rewrite engine to be on): RedirectMatch 404 .*/_vt.* Other than that, look out for odd URL requests in your logs. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
John Hunter wrote at 2004-9-25 11:46 -0500:
... Problem: IE on windows appears to want to use WebDAV, which doesn't understand cookies AFAIK and thus tries to reauthenticate using basic http authentication
Do you define a WebFolder to access your site? I have seen this behaviour for WebFolders (only). I am convinced that it is a bug in the WebFolders implementation which activates the relevant program without authentication information. It has nothing to do with CookieCrumber (which uses HTTP Authentication if available). -- Dieter
"Dieter" == Dieter Maurer <dieter@handshake.de> writes:
Dieter> John Hunter wrote at 2004-9-25 11:46 -0500: >> ... Problem: IE on windows appears to want to use WebDAV, >> which doesn't understand cookies AFAIK and thus tries to >> reauthenticate using basic http authentication Dieter> Do you define a WebFolder to access your site? No Dieter> I have seen this behaviour for WebFolders (only). I am Dieter> convinced that it is a bug in the WebFolders Dieter> implementation which activates the relevant program Dieter> without authentication information. It has nothing to do Dieter> with CookieCrumber (which uses HTTP Authentication if Dieter> available). You're right about cookie crumbler. As I noted in a later post, I get this on a standard zope install. I simply create a folder which requires authentication to view or access contents information. I place somefile.doc and index_html in there. I then access index_html, and authenticate. If I then try and open somefile.doc I get a http authentication dialog box again. This doesn't happen on a right-click save. The error log indicates the user agent generating this failed authentication is 'Microsoft Data Access Internet Publishing Provider DAV'. This happens only on IE on windows (never seen it on IE on mac) and only on some IE/windows combinations. Haven't been able to trace it to a specific browser version, or anything like that. Definitely repeatable across zope sites, all of which are using Zope-2.7.2 in various configurations. Haven't tested other zopes. JDH
participants (4)
-
Chris McDonough -
Chris Withers -
Dieter Maurer -
John Hunter