Summary: | Support document.execCommand("ClearAuthenticationCache") | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mackyle | ||||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED WONTFIX | ||||||||
Severity: | Enhancement | CC: | ap, fishd, julian.reschke, mackyle | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
mackyle
2010-08-28 10:53:04 PDT
I agree with Mozilla's stance on ClearAuthenticationCache - one Web application shouldn't be able to log you out from every other one you're logged in to, see <https://bugzilla.mozilla.org/show_bug.cgi?id=287957> for more discussion. So, I don't think that we are going to ever implement it. That said, there is an obvious need to have a way to drop stored credentials. > So there is an ugly hackaround available for Firefox <...> This is supposed to work in Safari, at least for Basic authentication scheme. Do you have an example page showing that it doesn't work? In WebKit nightlies, there is another way to log out - whenever a server returns 404, we forget stored credentials. So, this gives another way to log out, given server side support. This bug report talks about ClearAuthenticationCache specifically, so I'm closing it as WONTFIX. However, please feel free to file bugs about anything that works in Firefox, but not in Safari. A bug about coming up with a better solution wouldn't hurt, too - but we'll likely want to coordinate it with other browser vendors, so an even better thing to do would be e-mailing WHATWG mailing list. Safari version Version 5.0.2 (5533.18.5) still hangs on to invalid authentication credentials. However, the WebKit nightly builds correctly discard them, so presumably Safari will eventually pick up that fix. If you want to test locally, assuming you have an apache2 server that directs /cgi-bin requests to a scripts directory, add the attached logiotest.conf to your apache2 configuration and put the attached showuser script (making sure it's executable) in the real directory that /cgi-bin refers to. 1) Load /cgi-bin/showuser/login in the browser and provide any non-empty user id in the authentication dialog. The user id will be displayed in the loaded page as the value of REMOTE_USER. 2) In the same browsing session, now visit /cgi-bin/showuser/logout. Provide any non-empty user id in the authentication dialog. It will fail, then cancel the authentication request dialog when it pops up again. 3) Now, in the same browsing session, again visit /cgi-bin/showuser/login and it will show the failed user id from step (2) as the value of REMOTE_USER without even asking for a user/password authentication. In step (3), the WebKit nightly (and FireFox) always asks for a user/password, but Safari 5.0.2 (and earlier) do not. Safari instead stubbornly continues to use the bad user ID entered in step (2). Is there some reason that ClearAuthenticationCache can't be implemented to only clear the cache for the realm containing the page that called document.execCommand("ClearAuthenticationCache")? Created attachment 67068 [details]
Needed Apache2 configuration for login/logout test
Created attachment 67069 [details]
/cgi-bin/showuser script for login/logout test (must be executable)
> Is there some reason that ClearAuthenticationCache can't be implemented to only
> clear the cache for the realm containing the page that called
> document.execCommand("ClearAuthenticationCache")?
That's a reasonable idea.
I have two concerns about it:
- Implementing an IE-only feature in a way that's intentionally incompatible with IE would be confusing to authors, and just impolite. It might make sense to have a similar but differently named command in both Firefox and WebKit, but probably not as a WebKit-only feature.
- It's unclear whether credentials that are stored permanently in Keychain should be wiped out, too. It's bad UI to let Web pages delete credentials that were explicitly permanently stored by the user - but it's also bad to stay logged in after executing a command to forget credentials!
As mentioned above, WHATWG mailing list would be a good place to discuss better cross-browser solutions.
In regards to Comment #2 above, it looks like Safari 5.0.3 (6533.19.4) released 18 Nov. 2010 picked up the change that was in the WebKit nightly that allows Safari to correctly discard credentials when performing the steps listed there. See also Bug 42717 - A wrong password entered for site or proxy auth remains in WebCore credential storage, and is sent with subsequent requests: https://bugs.webkit.org/show_bug.cgi?id=42717 |