I just started using CookieCrumbler and it works well with the following exception: 1) I access a protected document and the login form is shown. 2) I attempt to login, but use an invalid username/password so it will fail. 3) At the failure screen, instead of clicking "try again", I attempt to access the protected document directly again. 4) Then, instead of getting the login form as I expect, my browser's basic auth window pops up. 5) If I then log in with basic auth and logout using manage_zmi_logout, my next attempt to access the protected document still brings up the basic auth window instead of the form. The only way I found to get back to the cookie auth is to restart my browser. :-( Is this a bug in CookieCrumbler? _______________________ Ron Bickers Logic Etc, Inc.
Ron Bickers wrote:
5) If I then log in with basic auth and logout using manage_zmi_logout, my next attempt to access the protected document still brings up the basic auth window instead of the form. The only way I found to get back to the cookie auth is to restart my browser. :-(
Is this a bug in CookieCrumbler?
I would say this is a bug in the HTTP spec. The HTTP spec doesn't actually provide a way to log out. See section 15.6 of the HTTP spec: ftp://ftp.isi.edu/in-notes/rfc2616.txt 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. ;-) Shane
-----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.
Ron Bickers wrote:
-----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?
Hmm, I see what you're saying now. It sets the cookie regardless of whether the name and password are valid. It should either not set the cookie, expire the cookie, or behave differently when cookie login was used but authentication failed. I'll look into it soon. Shane
participants (3)
-
Ron Bickers -
Ron Bickers -
Shane Hathaway