-----Original Message----- From: Shane Hathaway [mailto:shane@zope.com]
manage_zmi_logout just uses a method that usually works. If your browser doesn't do what you expect when it comes to logging out using HTTP AUTH, well... join the club. ;-)
I'm not sure I follow. The problem doesn't actually occur when I logout, but rather when I try to login. Shouldn't CookieCrumbler behave the same when I try to access a protected document after a failed login attempt as it does the first time I try to access it? This is easily reproducible. 1) Add a CookieCrumbler object and use the default "login" methods. 2) Create a DTML Document "protected.html" that is only viewable by a Manager. 3) Go directly to http://host/protected.html in your browser. Type an invalid login in the form. The "failure" page shows. 4) Go again directly to http://host/protected.html in your browser. No login form, but the basic auth window instead. What happens between step 3 and 4 that causes the CookieCrumbler to not show the login form? I thought it was supposed to "intercept" Unauthorized and show the form, but Zope is behaving as though there is no CookieCrumbler object at all. Also to clarify: If I login with a valid username, access is granted and everything works great. If I then logout using the CookieCrumbler's 'logout' method, I'm successfully logged out, the logout screen is displayed, and future attempts to access protected.html bring up the login form as expected. So essentially, everything works as expected. It's only if I try to access protected.html directly after a failed login attempt that this problem occurs. Do you still think HTTP AUTH is the culprit? _______________________ Ron Bickers Logic Etc, Inc.