Closed Bug 287957 Opened 16 years ago Closed 3 years ago
need a way for content to trigger a clearing of the HTTP auth session from script (.htaccess logout)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1 Since version 6 (SP1) MS Internet Explorer has had the function ClearAuthenticationCache <http://msdn.microsoft.com/workshop/author/dhtml/reference/constants/clearauthenticationcache.asp> which makes it easy to perform a .htaccess logout. I understand there is no similar function in Firefox, and this makes users prefer IE for certain tasks. I ask that ClearAuthenticationCache functionality is implemented in Firefox as well. Reproducible: Always Steps to Reproduce: 1. Perform .htaccess login 2. Realize that you can not log out if you use Firefox 3.
https://bugzilla.mozilla.org/show_bug.cgi?id=55181#c55 This is/will be implemented via UI but not with DOM0
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Component: Security → General
Resolution: --- → WONTFIX
There is similar function in Moz. Just no UI. Install Web Developer Tool (an extension) and you'll get an UI for this. http://www.chrispederick.com/work/firefox/webdeveloper/
That's not similar at all. That allows users to manually log out of HTTP auth. This bug was filed about giving *sites* the ability to clear the client's auth and force the client to reauthenticate. Specifically, Microsoft's ClearAuthenticationCache mechanism. Frankly it's not such a bad idea. Merchants can be on the hook to credit card companies if the user cries "fraud" (in the US, anyway). I'm sure they'd love the opportunity to make sure the user was really and truly logged out when they hit the log-out button on the page. Even if we have logout UI (and we do in the Suite) not many people are going to know to use it if they think they've done all they need to by clicking the "log out" button on the site. I can't see us supporting MS's syntax, though, and if we don't what is the likelyhood that sites would write code just for Firefox? Also a site shouldn't be able to log you out of all sites, just that one.
Well, it would clearly be best for developers if we could use the same code for IE and FF. But presently we have a choice for IE and no choice at all for FF. If it is absolutely neccessary to have a syntax different from IE I would still prefer that, compared to no syntax at all.....
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → EXPIRED
To me, this problem is as important as it was when I originally reported it. It is also the reason some of our users need to use IE. Unfortunately I am not able to help more than this, informing about the problem.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
*** Bug 324976 has been marked as a duplicate of this bug. ***
Exposing a way to log a user out of _all_ authenticated sessions without interaction in the same way IE works isn't something I want to expose to web content? Why should foo.com be able to log me out of bar.com? That said, being able to log out of the current HTTP auth session (i.e. if I'm logged into foo.com, foo.com can log me out of foo.com) would be acceptable, though I'm not sure why the site can't kill the session itself.
In my opinion, if you come out of a site that requires authentication, your authentication cache was to cleared automatically and when you come back to site, you must be requested to authenticate again. Unfortunately, W3 specifications are others (that needs to be changed) and the browser cache exists... By the way, the existence of a function to clear only the current domain that calls it is a good start...
Hixie, is this something WHAT-WG should spec? Darin, do we have an iface that will clear a single site's authentication? (I seem to remember we don't.)
Assignee: dveditz → nobody
Please note that I need solutions that "belongs" to browser by default. Various users will not agree to install extensions to perform clean-up of cache.
What is there to spec? Surely this should just be a menu item? There have been suggestions that you should be able to submit a form to HTTP auth, but it's not clear how that would work.
anything in the js console?
(In reply to comment #18) > anything in the js console? No. It runs with any errors but doesn't clear the cache. I run it on logout page. It gives me a security warning about the script. I click on "Allow" button, to allow script to run, and it runs without errors, but, when I return to site, I access it without user/pass dialog box. Another problem is the security alert because some users can be scared with it.
I've heard of one case where this is blocking institutional roll-out of Firefox. The situation is shared machines accessing an intranet and credentials being exposed to others. It's especially bad on Mac where closing the last browser window (but not exiting the app) doesn't clear the credentials like it does on Windows. Offering the intranet app a mechanism to clear credentials via JS would give Firefox parity with IE and make it easier for some institutions to switch to Firefox.
Moving to core, this is a Necko issue.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Summary: No .htaccess logout with FireFox → need a way for content to trigger a clearing of the HTTP auth session from script (.htaccess logout)
More than two years since this has opened and this is single handedly preventing me as a intranet web programmer from implementing NTLM Authentication. I can *not* rely on users to close their browser. This lack of functionality makes NTLM authentication a big security risk.
I was able to get the solution mentioned by Ilanio above to work when I delayed the xmlhttp.abort(); a bit, like this: setTimeout("xmlhttp.abort();", 100); But I still really miss this functionality in Firefox - the easiest solution in a Windows community is to use IE.
With increased use of OpenID and scripts such as phpMyId, which use HTTP Digest Authentication, the user risk involved in this issue is significantly increased. Once a user authenticates with such a script, a password is not required for *any* OpenID-enabled Web site to which the user has an account. Perhaps this is the fault of the script, but Firefox should supply some kind of mechanism for sites to clear the AUTH cache. : http://siege.org/projects/phpMyID/
We need some sort of spec for a sane way to log out a specific HTTP auth. The IE solution is terrible, one app shouldn't be able to log a user out of every http auth app they're using, especially without interaction. That type of model makes sense for a single window, single tab scenario (i.e. 1999) but in a "I have 137 tabs open" world its harmful to users.
Calling the code document.execCommand('ClearAuthenticationCache',true); in Firefox 18.104.22.168 throws me an exception: uncaught exception: [Exception... "Not enough arguments" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: http://...:81/ :: onclick :: line 1" data: no]
This bug has some good(and very long) discussion on how to implment this via content. https://bugzilla.mozilla.org/show_bug.cgi?id=55181 This post mentions how this is suggested by w3c https://bugzilla.mozilla.org/show_bug.cgi?id=55181#c10 My favorite suggestion for implementing this is a link for a specific domain and realm: about:logout?protocol=http&domain=www.zope.org+realm=Zope logout of all domain-realms: about:logout?protocol=http&domain=www.zope.org+realm=* logout of all domains: about:logout?protocol=http&domain=* originally suggested https://bugzilla.mozilla.org/show_bug.cgi?id=55181#c22 and refined https://bugzilla.mozilla.org/show_bug.cgi?id=55181#c36
Loading a magic URL isn't the ideal API to use from script. I'd suggest a simple API on the 'navigator' object, say, 'dropAuthentication', taking no parameters. It would just drop whatever authentication was used to load the current document.
I can't believe it, periodically I face always the same problem. I think the first time that I have discovered that IE was able to clear the authentication cache and FF wasn't, was in 2006. Now is about 4 YEARS that the users are asking for a way to clear the authentication cache and still there is any solution. I can imagine that the IE way is "so horrible", but at least they offer a solution. Is it "so horrible" to offer the same method as IE? At least meanwhile you guys think to the best way to do it (how many years do you still need?) we have at least something usable.
I think it's very easy to write a patch which implements the ClearAuthenticationCache function of Internet Explorer using nsIHttpAuthManager, but I can't write the patch for you cause I'm not a C programer.
it's not even possible from chrome js to remove a single entry. certainly no content should clearAll and no chrome would want to. just a matter of exposing: http://mxr.mozilla.org/mozilla1.9.2/source/netwerk/protocol/http/src/nsHttpAuthCache.h#243
See also WebKit bug <https://bugs.webkit.org/show_bug.cgi?id=44823>.
Same comment as many others. Please find some way to add the ability to clear the authentication. At the very least you could support document.execCommand('ClearAuthenticationCache') but only clear the authentication cache for the current domain. A better option would be something like: window.ClearAuthenticationCache(); Being able to Log Off from a site is such a basic option that this should really be a no-brainer. Even if you ask the user before clearing the credentials then that would still be a huge improvement over doing nothing. Thank you.
(In reply to Ilanio Castro from comment #20) > I found another script to clear the cache of FF. > > It uses a xmlhttp object to access the site with non-existent credentials, > clearing the cache. > Unfortunately, Firefox is now caching credentials so this technique no longer seems to work. See ticket #654348 https://bugzilla.mozilla.org/show_bug.cgi?id=654348
So, how are users supposed to log out? Should we (webmasters) just instruct them to use IE, which has this feature? Are really 10 years needed to move forward on this issue? Also don't forget about SSL client certificates, that have the same issue: they can "log in", but can never leave, as the song goes...
maybe the dom team can give some ideas.. http doesn't have a semantic
Component: Networking: HTTP → DOM
Bump. Still very much needed! Thanks.
I once proposed Session Management as an alternative to a logout or clear function on WhatWG mailing list. Perhaps this could still be useful. In short: - The website starts a session with window.sessionStart(). - With this the user-agent creates a new session context. The current session context becomes its parent. - The new session context is only valid for the current window. Just like sessionStorage. A possible exception could be opening new windows with the window.open function. - Any new http-auth tokens (either through XHR or UA-screen), sessionStorage data or session cookies will belong to the new session context and not its parent. - Any lookup for http-auth tokens, sessionStorage or session cookies done by the UA will not only look in the current session but will also traverse it parents. Script will be totally unaware of this. - When the website calls window.sessionEnd() the current session is destroyed with all http-auth tokens, sessionStorage data and session cookies that belong to it. And the parent session becomes the current session again. - Alternatively if the user closes the current window or navigates to another domain, the session also ends. In my origal proposal the is optional, specified by script as a boolean to the window.sessionStart function, defaulting to true. Script can now also set a timeout, ending a session after a period on inactivety and replace the current page with a message and offer the user to login again. This seems to me like a doable enough interface. That solves more than just the one issue of not being able to logout. Adding just two functions sessionStart/sessionEnd. Is totally backwards compatible as long as sessionStart/sessionEnd are never used. Do not impact anything beyond it's own window. Allows the user to have multiple sessions. Single sign on behavior could also be implemented this way. When a script calls sessionStart a UA can prefill the new session with http-auth tokens from some store. Now the UA no longer needs to ask for credentials and script will be blissfully unaware. I hope the idea helps.
Thanks Dave, great contribution. As said, still... this is very much needed and requested by our customers.
Status: NEW → RESOLVED
Closed: 16 years ago → 3 years ago
Resolution: --- → INVALID
I agree with Ondra on this one. Pawning off a 13-year-old RFE, especially one that still has the folks who have voted for it coming around to see if there is any movement on it, to some other project seems rather inconsiderate and short-sighted.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.