Bug 44823 – Support document.execCommand("ClearAuthenticationCache")

• Component: DOM
• Status: RESOLVED WONTFIX

EditorCommand.cpp <http://trac.webkit.org/browser/trunk/WebCore/editing/EditorCommand.cpp> does not currently support ClearAuthenticationCache.

When using HTTP authentication (via the 401 Authorization Required, WWW-Authenticate, Authorization mechanisms -- see RFC 2617 <http://tools.ietf.org/html/rfc2617>), there does not currently seem to be a way to clear the authentication cache in WebKit-based browsers so that the next request will always generate a log in dialog for the user.

This precludes providing a logout mechanism when HTTP Authentication is used.  Possibly this could even be considered a security hole as if the browser is not quit, another user could then access the page with the same cached credentials.

IE 6 sp1 and later (see <http://msdn.microsoft.com/en-us/library/ms536979.aspx>) support the ClearAuthenticationCache command (via document.execCommand) to provide this functionality and clear the authentication cache on the browser side without requiring any server-side support whatsoever.

Firefox also does not currently support ClearAuthenticationCache, however Firefox does clear the authentication cache for a specific authorization realm when it receives a 401 response after sending an authorization header.  In other words, if Firefox tries a cached user/password combination for an authorization realm and it fails (401 response), it clears the cache since there would be no point in trying that failing user/password combination again.  Safari, on the other hand, stubbornly hangs on to the last used user/password combination in the authorization cache even if it resulted in a 401 response.

So there is an ugly hackaround available for Firefox in that if you use a JavaScript XMLHttpRequest to retrieve an authorization required URI for the authorization realm you wish to log out of with an invalid user/password combination and then abort the request, Firefox will have cleared the authentication cache.  Safari, however, will not as it always hangs on to the last used user/password.  Regardless, this is an ugly hack as it generates unwanted traffic to the server as well as a server log entry and requires explicit server configuration to support.

Providing a means to clear the authentication cache without using hacky, non-documented solutions is desired for WebKit based browsers and document.execCommand("ClearAuthenticationCache") could provide that mechanism for WebKit just like it does for IE 6 sp1 and later.

[Alexey Proskuryakov]

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)

[Alexey Proskuryakov]

> 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