Last Comment Bug 55181 - Ability to log out of all sites using HTTP Basic authentication [forget/change/clear login info]
: Ability to log out of all sites using HTTP Basic authentication [forget/chang...
: arch, relnote
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
: -- enhancement with 27 votes (vote)
: ---
Assigned To: Vidar Haarr (not reading bugmail)
: 120092 129738 139405 139888 155811 157762 159045 160482 162051 171135 233008 233044 235346 238768 253765 (view as bug list)
Depends on:
Blocks: 68409 300002 61681
  Show dependency treegraph
Reported: 2000-10-04 09:38 PDT by Boris Zbarsky [:bz]
Modified: 2014-09-04 17:39 PDT (History)
53 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

debugging logs and a scenario where the current fix doesn't work (70.25 KB, application/octet-stream)
2003-07-22 12:40 PDT, Casey Crabb
no flags Details
adds a httpAuthPasswordExpire function (1.76 KB, patch)
2004-09-15 23:50 PDT, Vidar Haarr (not reading bugmail)
neil: review-
Details | Diff | Review
updated to neils comment 92 suggestions (1.85 KB, patch)
2004-09-16 16:51 PDT, Vidar Haarr (not reading bugmail)
neil: review+
Details | Diff | Review
updated to neils comment 95 suggestions (1.47 KB, patch)
2004-09-17 03:35 PDT, Vidar Haarr (not reading bugmail)
vhaarr+bmo: review+
darin.moz: superreview+
Details | Diff | Review
updated to darins comment 99 suggestions (1.78 KB, patch)
2004-09-19 23:25 PDT, Vidar Haarr (not reading bugmail)
neil: review+
darin.moz: superreview+
Details | Diff | Review

Description Boris Zbarsky [:bz] 2000-10-04 09:38:00 PDT
Right now Mozilla seems to be doing exactly what Netscape did, which is cache
the BasicAuth username/password for a particular Auth zone and not reprompt the

This is fine, but it also does not give the user a way of logging out of a site
without quitting the browser.

Ideally, there would be a way to log out both by having the user select some
option from a menu and by having a user click on a link.
Comment 1 Boris Zbarsky [:bz] 2000-11-01 21:41:07 PST
Confirming this enhancement request.

mpt: where should this go?  Is networking the right component?

Clarifying the first comment:

1) It would be good if the user could log out (clear their remembered password)
by clicking a button somewhere in the browser (on the url bar?)

2) It would also be good if site authors could provide a "logout" button that,
when clicked would trigger some function that would clear the cached password.

It's not clear whether it's possible to do 2), since that seems to involve some
sort of extensions to JavaScript, which is something to avoid.
Comment 2 Darin Fisher 2000-11-20 19:13:47 PST
Suggestion (1) requires an addition to the current HTTP interfaces.  Not a
problem IMO.  This will be discussed at the next API review.

Suggestion (2) is much more involved.  It is not supported by the HTTP protocol,
and never will be, since HTTP is stateless.  As far as a JS way of solving this
problem, I wouldn't really know.  My guess is that it wouldn't be a very clean

IMO: suggestion (1) is easy to do and would probably satisfy most users.
Comment 3 Darin Fisher 2000-11-30 12:55:11 PST
added keyword arch.
Comment 4 Darin Fisher 2000-11-30 13:09:13 PST
added RFE to summary.
Comment 5 Gagan 2001-01-23 11:14:50 PST
about:logout may be the easiest solution. cc'ing conrad who also has an interest 
in this.
Comment 6 Darin Fisher 2001-01-23 11:24:30 PST
wouldn't about:http make more sense?  there could be a logout button with a
description of what this means.
Comment 7 Conrad Carlen (not reading bugmail) 2001-01-23 11:36:23 PST
Suggestion (1) would be good API-wise. If a logout() method were put on the http
handler. Currently, the time at which this logout occurs is when a profile
switch happens. The http handler is a profile change observer. If there was a
logout method on http handler, then a higher-level profile change observer could
call it. This would switch the dependency around: instead of the http handler
being dependent on nsIProfileChangeStatus.h, some other profile change observer
would have to call http handler and tell it to log out. I'm not sure why we need
UI specifically to make a logout happen. It seems to be a natural part of a
profile switch - or at least a profile logout - which is a variation on the
profile switch that I need to do.
Comment 8 Darin Fisher 2001-01-23 11:54:26 PST
A UI could also list the authenticated sites.  But, that is really just a
feature that may or may not be deemed important.  So, I agree with you that
the HTTP handler could just provide an API to allow a higher level profile
change observer control over HTTP logout... but what is wrong with letting HTTP
be a profile observer itself?  I'm not sure I see the distinction between these
two solutions.
Comment 9 Conrad Carlen (not reading bugmail) 2001-01-23 12:10:15 PST
> but what is wrong with letting HTTP be a profile observer itself?  I'm not sure
> I see the distinction between these two solutions.

IMO, there isn't a problem with that. It caused a dependency to show up between
necko and profile on the dependency tracking senna Tinderbox. Depends on how you
look at it...
Comment 10 Matthew Paul Thomas 2001-02-10 03:39:18 PST
W3C `Common user agent problems' <>, 
1.8: Provide a mechanism to allow authentication information to expire.
Comment 11 Matthew Paul Thomas 2001-02-10 03:39:36 PST
*** Bug 68409 has been marked as a duplicate of this bug. ***
Comment 12 Gagan 2001-02-11 15:09:29 PST
catching up on this bug... I don't think we should split the about:logout idea 
on a per protocol basis. As a user I may have use auth in an FTP or an HTTP 
transaction and would just like to logout from all those without having to 
restart the browser. While about:http could *still* be a good idea to give HTTP 
specific stats, this issue of just resetting auth info should be handled 
Comment 13 Matthew Paul Thomas 2001-02-12 04:36:33 PST
UI-wise, I think there should be a `Security Manager' window, with a tab showing 
a list of things you were currently authenticated to, and a button for logging 
out of the selected authentication. (PSM, if compiled, would add other tabs to 
this window.)
Comment 14 Conrad Carlen (not reading bugmail) 2001-02-12 05:17:03 PST
I have a bug which may be relevant: bug 65212. It is about being able to log out
of the browser without shutting down. It will leverage the profile switching
observers (HTTPHandler is hooked up to this). I think UI-wise, it would be a
problem if the user had to log out of different things in a piecemeal manner.
Since this is for embedding, like profile switching itself, the UI work is not
being done for SeaMonkey but would be pretty simple.
Comment 15 Boris Zbarsky [:bz] 2001-02-12 11:41:58 PST
Actually, logging out of things in a piecemeal manner was exactly what this rfe
was for originally.  I would like to be able to log out of one specific site at
a time.

If there is also a bug logout functionality (like "log out of this profile")
then I would want it to not only log out of all HTTP authentication stuff but
also to close off access to bookmarks and preferences for that profile.  But
that's not the purpose of this bug.
Comment 16 Gagan 2001-03-15 18:45:13 PST
Comment 17 Keyser Sose 2001-03-17 00:27:27 PST
*** Bug 69011 has been marked as a duplicate of this bug. ***
Comment 18 benc 2001-05-23 12:35:29 PDT
mass move, v2.
qa to me.
Comment 19 benc 2001-06-26 10:31:15 PDT
Shouldn't we implement dropping auth values as part of the -turbo feature?
Comment 20 Conrad Carlen (not reading bugmail) 2001-06-26 10:39:24 PDT
I'm working on that. The code in http auth is already there - it just needs to
be triggered by a profile shutdown which is what turbo mode is going to do.
Comment 21 Gervase Markham [:gerv] 2001-09-03 18:38:22 PDT
Conrad: what's the score here? The Zope folks would love to see this feature. 

As for a web page providing a logout button, couldn't it be a link to:
about:logout could provide a list of domains and a button marked "Everything" or

Comment 22 Matt Behrens 2001-09-04 04:30:53 PDT
Don't forget the realm.


or something similar...

Logout functionality is really the only reason I use that icky form-based
authentication -- because I can always destroy the cookie...
Comment 23 Matthias Versen [:Matti] 2002-01-18 13:54:18 PST
*** Bug 120092 has been marked as a duplicate of this bug. ***
Comment 24 Matthias Versen [:Matti] 2002-03-08 14:35:12 PST
*** Bug 129738 has been marked as a duplicate of this bug. ***
Comment 25 Mark Bitterling 2002-03-31 06:32:18 PST
I see that there is not a Target Milestone set for this bug.  Is anyone working
on it, or is there help wanted?
Comment 26 Matthias Versen [:Matti] 2002-03-31 08:49:25 PST
Patches are always welcome !
Comment 27 Mark Bitterling 2002-04-03 09:47:08 PST
Well I am researching and trying to get familiar with the relevant code, but it
will be a few weeks before I can give it any real attention.  Even then don't
expect a patch from me right away because my CodeWarrior needs upgrading 

BTW, donations of upgrade for CodeWarrior would be accepted.  :)
Comment 28 Boris Zbarsky [:bz] 2002-04-24 22:20:54 PDT
*** Bug 139888 has been marked as a duplicate of this bug. ***
Comment 29 Philip White 2002-04-26 21:13:41 PDT
*** Bug 139405 has been marked as a duplicate of this bug. ***
Comment 30 Arthur 2002-04-29 02:23:20 PDT
Hm, Netscape 4.x and Opera on linux let you "log out" with this php function on
the server:

function manage_logout() {
	// clear existing ACL, and set the expired flag
	$acl = array('expired' => 2);
	$GLOBALS['HTTP_SESSION_VARS']['acl'] = array('expired' => 2);

You can log in as a different user afterwards. With mozilla, this doesn't work.
Is there no way at all to trigger a new login-prompt without using a cookie?
Comment 31 Jim 2002-05-23 03:21:24 PDT
The PHP func referred to uses an auth method that's internal to PHP as far as
I'm aware - ie, it uses cookies and/or GET/POSTed data to pass through a session
key. Cookies themselves cannot cause the browser to prompt for HTTP
authentication, although they may prompt server-side scripts to prompt for HTTP

Sending an HTTP 401 response (after the browser has sent valid authentication
data) is an (the only?) effective way of 'poisoning' the password cache and
prompting the browser to request a new password, ie a hypothetical perl (apache)

sub poisonauth {
   print "Status: 401 Unauthorised\n\n"

The problem is that the browser will then (RFC2616 says 'may' but I've yet to
see a browser not do so) retry the new authentication with the same URL, leaving
the server-side scripts with the minor headache of how to tell when (not to)
send a 401. The other issue is that the 401 response means that the
authentication data is actually wrong (or not present), not that it's expired or
that the user wants to log out.

As far as achieving logout in mozilla is concerned, I suppose it would be
possible to loop a request for the same page through itself and send itself a
401 response, but that would be a horribly ugly hack. Best way, I suppose would
be to  just find and delete whatever data structure holds the authentication cache.
Comment 32 Darin Fisher 2002-05-23 15:21:58 PDT
i was thinking about adding a button for this in the HTTP Networking prefs...
but i'm not sure how to describe the button... afterall, not all websites use
HTTP authentication to authenticate users :-/
Comment 33 Gervase Markham [:gerv] 2002-05-23 15:34:23 PDT
darin: what's wrong with the about:logout idea? It has the considerable
advantage that websites can put a "logout" button on their pages themselves.

Comment 34 Darin Fisher 2002-05-23 15:45:18 PDT
hmm... i like both actually... UI is good for users, but having an URL scheme is
really great for websites... we could even support a syntax like this:


reassigning to me.
Comment 35 Darin Fisher 2002-05-23 15:46:19 PDT
about:http-logout might be better, or


Comment 36 Gervase Markham [:gerv] 2002-05-23 16:09:28 PDT
about:logout?protocol=http& ?

This is more extensible to other protocols. FTP, for example. For bonus points,
support about:logout?protocol=http&domain=* to log out of everything.

Are there any issues here with malicious sites logging you out of somewhere and
then reprompting for your credentials? Can we only let about:logout work from
web content where the domain matches the current URL?

Comment 37 Darin Fisher 2002-05-23 16:40:03 PDT
yes, i think we could limit websites access to about:logout based on the URL's

cc'ing mitch
Comment 38 Jim 2002-05-24 02:42:42 PDT
Actually, I suppose you could use the protocol also, leaving you with
'about:logout?realm=foo' (implied '&protocol=bar&host=baz&port=whatever'). After
all, you can't have more than one protocol on the same host/port.

As far as UI is concerned, I was thinking we could just have File->Logout (same
as with MSIE when it uses FTP) or File->'Logout <username>' menu option.
Comment 39 Matt Behrens 2002-05-24 04:30:07 PDT
Okay, I'm all thoughtful today.  Sorry. :-)  But is about: really the correct
scheme for this?

A question, first: does or Netscape have an RFC2717 tree for
defining new schemes?  Then, perhaps, something like
moz-logout:http/ could work.

Or, perhaps (and I don't know how abusive this is, this isn't my favorite idea), (null password) to log out?
Comment 40 Mitchell Stoltz (not reading bugmail) 2002-05-24 12:38:25 PDT
Sure, we can add a security check for about:logout or whatever scheme we end up
using. I'm not sure if we can use an existing check in nsIScriptSecurityManager
or if we'll need to write a new function, possibly living in the new protocol
handler, but either way will work. Darin, let me know when you or whoever gets
to implementing this, and I'll help with the security side.
Comment 41 benc 2002-06-05 08:32:14 PDT
How about X-Logout:

I really don't like the way we keep abusing the scheme URL namespace.

Please look at bug 130089.
Comment 42 Matthias Versen [:Matti] 2002-07-04 12:33:23 PDT
*** Bug 155811 has been marked as a duplicate of this bug. ***
Comment 43 Matthias Versen [:Matti] 2002-07-16 12:09:30 PDT
*** Bug 157762 has been marked as a duplicate of this bug. ***
Comment 44 Matthias Versen [:Matti] 2002-07-23 23:06:45 PDT
*** Bug 159045 has been marked as a duplicate of this bug. ***
Comment 45 Bradley Baetz (:bbaetz) 2002-08-01 07:05:59 PDT
*** Bug 160482 has been marked as a duplicate of this bug. ***
Comment 46 Stephen P. Morse 2002-08-01 07:35:33 PDT
Bug 160482 has just been marked as a dup of this one.  But that bug makes an
additional point that is worth repeating here.  Namely that the password manager
already gives a "log out" menu choice so that the user can relock the
password-manager database (in the event that it was encrypted and he already
supplied the master password).  So the user would expect that by selecting that
choice, that he is also logged out of basic auth.  Of course that's not the
intent of the password-manager log-out at all, but perhaps it should be.  In
other words, whatever facility (if any) is decided to provide the log-out for
basic auth requested here, the password-manager log-out choice should accomplish
it as well.
Comment 47 benc 2002-08-01 14:39:58 PDT
Good point. Please file a bug in Password Manager for that, because it will
likely require separate code to implement.
Comment 48 benc 2002-08-09 09:44:30 PDT
Comment 49 Boris Zbarsky [:bz] 2002-08-10 02:52:39 PDT
*** Bug 162051 has been marked as a duplicate of this bug. ***
Comment 50 Boris 'pi' Piwinger 2002-09-27 03:33:00 PDT
*** Bug 171135 has been marked as a duplicate of this bug. ***
Comment 51 Michael T. Babcock 2002-11-18 12:29:19 PST
Can I suggest thinking 'outside the box' a little here?  I don't think I've seen
a browser give me more information about my current session that Netscape 2.0. 
The little lock was added to say you're on a secure site (it should be right
next to the address bar IMHO) and the progress bars have been added.

Why don't we look at some Chrome design for actually telling the user that the
current page requested 4 cookies (cookie image drop-down?) and is part of an
authentication realm 'Basic Auth Site 42' (drop-down from certificate symbol?).

Just some thoughts ...
Comment 52 Boris Zbarsky [:bz] 2002-11-18 12:51:15 PST
Thinking outside the bug is nice... and has nothing to do with this bug.  This
bug is for one thing and one thing only -- the ability to forget BasicAuth login
information, either for a given site or for all sites.  I don't even care if
there is UI; as long as the HTTP protocol handler has support for this, I can
hack together UI, install it locally, and be happy.

Darin, are there plans to freeze nsIHttpProtocolHandler any time soon?  If there
are, I'll try writing up some api suggestions....
Comment 53 Darin Fisher 2002-11-18 13:06:34 PST
no plans to freeze nsIHttpProtocolHandler anytime soon.
Comment 54 Henrik Gemal 2003-01-08 05:24:43 PST
IE has this:

Can be tested at: login in with:
login: test
passwd: test
Comment 55 Boris Zbarsky [:bz] 2003-01-08 06:44:30 PST
IE has the _back_end_ for this.  It does not have usable UI.... (though it does
allow the web developer to do it, but not the user).  Let's please not implement
it that way.  ;)
Comment 56 Kai Engert (:kaie) 2003-01-29 14:44:47 PST
I agree with comment 46.
Comment 57 Chris Croome 2003-02-26 08:36:29 PST
Seairth Jacobs has made some user interface suggestions on the REST list that I
think might be of interest in relation to this bug:

Here are some suggestions:

1) When a browser is sending authentication with each request, prominantly
provide a button on the screen labeled "clear authentication" (or some
such). A user can click on this at any time to force the browser to dump
the authentication.

2) When the user leaves the authenticated page/realm, have the browser
prompt the user as to whether the authentication information should be
cleared or not. This way, a user does not have to depend on #1 above or on
closing the browser in order to go to another website.
Comment 58 Matthijs Melchior 2003-02-28 08:43:30 PST
A user interface for managing Basic Authentication UID:password pairs fits in
the "Page Info/Security" dialogue.  Clicking on the bottom right lock, it gives me
a window with only 2 of the 3 security properties.  It has info about how the
browser verifies the web-site, about the encryption status of the communications
link, but NOT about how the web site verifies the browser-user's identity....
This is the Basic Authentication info, and it can have a button to remove
(or change) it.
Comment 59 Alon Altman 2003-02-28 08:57:29 PST
About comment 58, I think that the "page info" dialog is a good place to put the
INFO about BasicAuth, but I think you should file a seperate bug (RFE) for
putting that info there.

The ACTION to logout from BasicAuth can be placed under "page info", but that
shouldn't be the only place it's found.

Maybe a "LOGOUT" button (with some graphic, perhaps a door with arrow pointing
out) should be placed in the bottom-right corner of the browser window iff
you're in a BasicAuth site, in addition to an option under the Tools menu to
manage BasicAuth sites (similar to the cookie manager, maybe even combined with it).
Comment 60 Darin Fisher 2003-03-20 22:53:57 PST
nsIHttpAuthManager is coming online... see bug 60304.  it includes a ClearAll
method.  this could be used to expose this functionality via the UI.

-> future
Comment 61 Gervase Markham [:gerv] 2003-03-20 23:23:51 PST
darin: are you sure that's the bug number? The patch there doesn't contain a
method like that...

Also, is there a Clear() method, for logging out of a single site? That would be
most cool :-)

Comment 62 Darin Fisher 2003-03-21 00:31:37 PST

see .. the
first of the two patches in the bug.  sorry, i should have been more specific.

no, it doesn't include a method to logout of a single site.  we could easily add
that though.
Comment 63 Gervase Markham [:gerv] 2003-03-21 00:41:37 PST
Cool. Basically, that's what this bug requests: a Clear(realm) method, a button
in the UI which calls it with the current realm, and a way of determining when
to show the button. :-)

Comment 64 Henrik Gemal 2003-03-21 00:53:35 PST
I think it's pretty important that we have something like:
command available via JavaScript


having to guide users to some menu UI is also impossible.
Comment 65 Mark Bitterling 2003-04-03 04:02:09 PST
I see that a patch for bug 60304 has now been checked in.

I see where the nsIHttpAuthManager has the ClearAll method that Darin mentioned
in comment 60, as far as could tell from my very brief look at the patch, the
Clear method needed for this bug still needs to be implemented.

Are any of the bug 60304 patch authors planning to now tackle this bug?

As I have mentioned previously, I am quite willing to try to help write a patch,
but my available time and my familiarity with the Mozilla code are both rather
limited.  With the recent changes to the Mozilla Roadmap, I would really like to
see this implemented in 1.4 if at all possible.  Unfortunately, I am not sure
that I could find the time to write a patch for this bug before 1.4 is frozen.

I ought to have some extra time to work on it this summer, but obviously that is
too late for 1.4; if 1.5 were just going to be another milestone then there
would not be a big deal to me, but with the switch to Phoenix going on, it
becomes a more important issue to get it into 1.4.

Is there anyone more capable than me who is planning to try to get this into
1.4?  If not, will it be possible to get a patch for this into 1.4.x at a later
Comment 66 Calum Mackay 2003-04-11 03:00:48 PDT
I've logged a separate bug 201620 for the case where mozilla caches user/pass
even when it results in a 401 error. i.e. get your password wrong and you have
no way of re-trying.

I believe that is a bug which is separate from this RFE, although this RFE would
obviously help workaround that bug. Comments?
Comment 67 Mark Bitterling 2003-04-29 12:28:01 PDT
If I were to write a patch for this bug, is there ANY chance that it could ever be checked into the 
1.4.x branch?  Or is it simply too late?  

I realize that it can always be checked in for 1.5 or later, but I'd like to know whether or not the 
powers that be would balk at having it checked into 1.4 after the trunk has moved on to 1.5.
Comment 68 Gervase Markham [:gerv] 2003-04-29 14:57:06 PDT
It depends on the complexity of the patch; but if it didn't make 1.4 final, I
doubt it would get into the 1.4 branch for several months, because some
companies may want to ship some products, so they'd be in stabilisation mode.

Comment 69 benc 2003-04-30 04:59:44 PDT
Mark: you need to talk to the module owner, who is Darin. Some of the powers
that be want related problems fixed, but I think this is going to depend on what
is wrong and how complicated the fix is.

There are several related bugs, which describe the same problem: after you get a
401, and type in some user:password info, those credentials are mindlessly used
again and again. Even if a 401 forces a new auth dialog, the old data is used.
Even if the URL has userpass info, (which throws up an auth dialog), the old
data is used. Even composer, which allows you to type in new userpass info for
each time you save to the same URL cannot stomp out the cached data from your
first try. So it sounds like there is just one crutial spot where HTTP makes a
wrong turn, but you never know until you start fixing...

A clear button might be orthogonal to the problem... we seem to lack a larger
design process, but I am beginning to think we need magic clear buttons in the
UI for the variety of cached data that seems to force people to restart because
they get stuck.
Comment 70 Matthias Versen [:Matti] 2003-07-19 21:25:12 PDT
*** Bug 213203 has been marked as a duplicate of this bug. ***
Comment 71 Casey Crabb 2003-07-22 12:40:37 PDT
Created attachment 128269 [details]
debugging logs and a scenario where the current fix doesn't work

Using nightly Firebird from 22nd July 2003:
Having a problem where if a user clicks on a link that specifies credentials it
will appropriately load page, but if user clicks on a link from the page
brought up it will ask for credentials again. Logs and the exact scenario in
the zip file.
Comment 72 Hugo 2003-07-25 07:52:29 PDT
>Right now Mozilla seems to be doing exactly what Netscape did, which is cache
>the BasicAuth username/password for a particular Auth zone and not reprompt the

>This is fine, but it also does not give the user a way of logging out of a site
>without quitting the browser.

I think this is not fine always... I think this could be security flaw in some
Hi, my name is Hugo, from Infohacking ( We have been
researching and exploiting Cross Site Scripting vulnerabilities in many
scenarios for the last months. A browser caching the BasicAuth username/password
for any browser instance, exposes the user to trivial user impersonation on
those scenarios where Basic Auth is used. If an authenticated user with basic
auth with mozilla opens a new window and goes to the same realm, the user is
automatically loggued in. This implies that if the user has mozilla as default
browser, a malicious link in an e-mail, webpage, etc can be used to force the
target user to access a protected realm zone. 
The browser must be aware of the "state" of the session. From where comes this
request? Comes from the same window where I already have been validated or does
it comes from another window...?

Comment 73 John Levon 2004-01-25 08:40:40 PST
Extension utilising the new AuthManager API until real UI arrives:
Comment 74 Jesse Ruderman 2004-02-03 17:15:49 PST
*** Bug 233008 has been marked as a duplicate of this bug. ***
Comment 75 Jo Hermans 2004-02-04 05:37:32 PST
*** Bug 233044 has been marked as a duplicate of this bug. ***
Comment 76 Bill Mason 2004-02-23 15:03:21 PST
*** Bug 235346 has been marked as a duplicate of this bug. ***
Comment 77 Robert Wall 2004-03-26 04:58:51 PST
*** Bug 238768 has been marked as a duplicate of this bug. ***
Comment 78 Henrik Gemal 2004-03-30 04:28:53 PST
the code from Clear HTTP Auth:
var isupports =
var mHAService = isupports.QueryInterface(Components.interfaces.nsIHttpAuthManager)

now we just need to add the menuitem and expose the function to JavaScript
Comment 79 Bill Mason 2004-07-30 14:00:44 PDT
*** Bug 253765 has been marked as a duplicate of this bug. ***
Comment 80 David Balažic 2004-09-15 06:35:54 PDT
"now we just need to add the menuitem and expose the function to JavaScript"

I guess adding a menu item ( or a button ) is a very complicated thing...
Comment 81 Boris Zbarsky [:bz] 2004-09-15 09:35:15 PDT
If it's not, let's see it, please.
Comment 82 Gervase Markham [:gerv] 2004-09-15 09:57:46 PDT
Sounds to me like an ideal thing for an extension (and, in fact, I believe the
Web Developer Toolbar offers this functionality.)

Comment 83 Christian :Biesinger (don't email me, ping me on IRC) 2004-09-15 10:03:47 PDT
can we make password manager's log out feature clear http auth, too?
Comment 84 Boris 'pi' Piwinger 2004-09-15 10:18:23 PDT
Gerv, I disagree. This is a very basic functionality. Also there is a very 
confusing entry in the menus where people (rightfully!) expect this to happen.

Comment 85 Gervase Markham [:gerv] 2004-09-15 14:22:32 PDT
"Very basic functionality" that no browser has ever had since the dawn of time? 

Still, I like biesi's solution. This doesn't need extra UI.

Comment 86 Aaron Kaluszka 2004-09-15 16:08:22 PDT
One possibility: A status bar icon that shows current username on mouseover
"Currently logged in as ___" either as a tooltip or on the status bar.  Clicking
on this icon would pop up a menu item for allowing logout.  I could look at this
if I had time, but I don't... if nobody gets to it in the next few months, I
might look at it then.
Comment 87 Vidar Haarr (not reading bugmail) 2004-09-15 23:50:59 PDT
Created attachment 159068 [details] [diff] [review]
adds a httpAuthPasswordExpire function

Something like this, then? I'm terribly sorry, but don't have time to actually
_test_ it right now :) I'll get to that later today.
Comment 88 David Balažic 2004-09-16 00:40:09 PDT
Very funny, boris. I'm a user/tester, not a developer ( as far as mozilla is
concerned ).

Gervase Markham :
""Very basic functionality" that no browser has ever had since the dawn of time? "

Others don't care about security, so mozilla should't either ?

Comment 89 Anne (:annevk) 2004-09-16 00:48:16 PDT
This was brought up at the WHATWG as well.

Shouldn't the HTTP specification be updated with a new logout status? See also
some ideas here:
Comment 90 Gervase Markham [:gerv] 2004-09-16 13:29:28 PDT
> Others don't care about security, so mozilla should't either ?

Oh come on, that's a ridiculous caricature of my position. 

No-one gets more secure with this feature; it's just a convenience for web
developers. These sort of sites always say "close your browser"; if people don't
do that, they won't remember to logout either.

I'm not saying we shouldn't do it, I'm saying it doesn't need 15 pixels of fame.

Comment 91 Vidar Haarr (not reading bugmail) 2004-09-16 14:54:54 PDT
Comment on attachment 159068 [details] [diff] [review]
adds a httpAuthPasswordExpire function

I've tested the patch now, and it worked fine (SquirrelMail).

Neil, could you review?
Comment 92 2004-09-16 15:59:32 PDT
Comment on attachment 159068 [details] [diff] [review]
adds a httpAuthPasswordExpire function

>+    // Queries the HTTPAuth Manager and clears all sessions
>+    function httpAuthPasswordExpire() {
>+      var httpAuth = Components.classes[';1'];
>+      httpAuth = httpAuth.getService();
>+      httpAuth = httpAuth.QueryInterface(Components.interfaces.nsIHttpAuthManager);
>+      httpAuth.clearAll();
>+    }
Firstly, I don't understand why you added this function after
walletPasswordExpire, as it gets called first.

Secondly, you copied the old coding style of walletPasswordExpire.
getService now takes an optional parameter saving you the separate
QueryInterface step.
Furthermore, we try to avoid single-use variables. In this case you just need
to put each method call on its own line, lining up the dots.

As you're bound not to have understood me, I'll give you an r- so I can see the
next patch ;-)
Comment 93 Vidar Haarr (not reading bugmail) 2004-09-16 16:51:18 PDT
Created attachment 159143 [details] [diff] [review]
updated to neils comment 92 suggestions

Patch updated to latest getService(...) usage. I also converted
walletPasswordExpire just for fun.

According to comment 88, I don't think Mr. Balažic will care if I take this
Comment 94 Vidar Haarr (not reading bugmail) 2004-09-16 16:54:28 PDT
Comment on attachment 159143 [details] [diff] [review]
updated to neils comment 92 suggestions

Neil, could you review again, please?
Comment 95 2004-09-17 03:12:40 PDT
Comment on attachment 159143 [details] [diff] [review]
updated to neils comment 92 suggestions

I'll assume you can fix these tweaks without further reviews :-)

>+      Components.classes[';1'].
>+            getService(Components.interfaces.nsIHttpAuthManager).
>+            clearAll();
I knew you would misunderstand something ;-) When I said line up the dots, I
mean that your second and third lines should have leading dots which line up
under the . after Components rather than having trailing dots on your first two

>+      var wallet = Components.
>+            classes[';1'].
>+            getService(Components.interfaces.nsIWalletService);
If you really want to wrap this can you put the Components on the second line
too (2-space indent)? (And the dot needs to be before getService and lined up
of course.) Or you could just leave this change out ;-)
Comment 96 Boris 'pi' Piwinger 2004-09-17 03:28:15 PDT
>> Others don't care about security, so mozilla should't either ?
> Oh come on, that's a ridiculous caricature of my position.

At least people have asked about it and the function in the menu which
you would expect you to log out of a site.

> No-one gets more secure with this feature; it's just a convenience for web
> developers.

I don't see developers have to do with it. It is user who want to log out.

> These sort of sites always say "close your browser"; if people don't
> do that, they won't remember to logout either.

Myself I often open several windows. I don't want to close everything just to 
get out of only one site.

Comment 97 Vidar Haarr (not reading bugmail) 2004-09-17 03:35:01 PDT
Created attachment 159188 [details] [diff] [review]
updated to neils comment 95 suggestions

I've removed the walletPasswordExpire change and lined up the dots.
Comment 98 Vidar Haarr (not reading bugmail) 2004-09-17 03:37:00 PDT
Comment on attachment 159188 [details] [diff] [review]
updated to neils comment 95 suggestions

Carrying over r=neil.
Darin: could you sr, please?
Comment 99 Darin Fisher 2004-09-17 09:38:37 PDT
Comment on attachment 159188 [details] [diff] [review]
updated to neils comment 95 suggestions

>+    // First clears the HTTP auth, then the Wallet
>+    function expireHTTPAuthAndWallet() {
>+      httpAuthPasswordExpire();
>+      walletPasswordExpire();
>+    }
>+    // Queries the HTTPAuth Manager and clears all sessions

nit: "HTTP Auth Manager"

also, i would have just put the code for clearing wallet and
the HTTP auth manager inside expireHTTPAuthAndWallet since 
each is just a one liner.  (i liked the fact that you were
cleaning up walletPasswordExpire!)

sr=darin (but please create a revised patch, thx!)
Comment 100 David Balažic 2004-09-17 15:50:20 PDT
Does this bug also cover FireFox ? Does FF has its own bug ?

Also how about forgetting an FTP login ? At least in FF I see no way to "logout"
from an FTP login. I close the FTP page, open a new one, enter the URL (
ftp://user@site format , note no password ) and it shows the FTP listing,
without asking for a password. I can also list other directories ( that werent
visited before ) and again no password is asked.
Comment 101 Christian :Biesinger (don't email me, ping me on IRC) 2004-09-17 16:16:52 PDT
>Does this bug also cover FireFox ?

Comment 102 Darin Fisher 2004-09-17 16:55:24 PDT
The deal with FTP is that you may have some authenticated control connections
already open, or in the case of directory listings, those may be in the
browser's cache.  (I believe that we cache FTP directory listings for a short

You have a very similar problem with HTTP and authentication protocols like NTLM
and Negotiate (a.k.a. SPNEGO).  Those authentication protocols are "connection
oriented", which means that you only have to authenticate when you first
establish the connection.  Then, through the magic of HTTP keep-alive
connections, you can reuse the connections without re-authenticating for each
request.  This means that in order to "really logout", you'd need to close any
keep-alive connections as well as flush the password cache(s).
Comment 103 David Balažic 2004-09-18 02:26:23 PDT
Here is a tested scenario ( admittedly, with FireFox ) :
Go to a coworkers (or anyone elses) PC, login to some FTP site, do something,
close the browser window, walk away. The coworker ( or whoever he is ) reenters
the URL of your FTP site and has full access.
Comment 104 Peter van der Woude [:Peter6] 2004-09-18 04:03:23 PDT
*** Bug 260186 has been marked as a duplicate of this bug. ***
Comment 105 Vidar Haarr (not reading bugmail) 2004-09-19 23:25:23 PDT
Created attachment 159459 [details] [diff] [review]
updated to darins comment 99 suggestions

Moved the httpAuthPasswordExpire() into expireHTTPAuthAndWallet() and also
cleaned up walletPasswordExpire()'s QI.
Comment 106 Vidar Haarr (not reading bugmail) 2004-09-19 23:28:28 PDT
Comment on attachment 159459 [details] [diff] [review]
updated to darins comment 99 suggestions

Requesting reviews from Neil and Darin all over again. I'm a bit confused as to
what I should actually do in the patch - clean up or not. So you guys decide ;)
Comment 107 Darin Fisher 2004-09-20 12:39:16 PDT
Comment on attachment 159459 [details] [diff] [review]
updated to darins comment 99 suggestions

sr=darin provided Neil is happy with this patch.
Comment 108 2004-09-20 15:41:01 PDT
Comment on attachment 159459 [details] [diff] [review]
updated to darins comment 99 suggestions

>+      walletPasswordExpire();
>+    }
>     function walletPasswordExpire() {
I'm happy if darin's happy with leaving these four lines in ;-)
Comment 109 2004-09-21 09:11:43 PDT
Fix checked in, without those lines :-)
Comment 110 2004-09-21 09:12:03 PDT
Fix checked in, without those lines :-)
Comment 111 Vidar Haarr (not reading bugmail) 2004-09-21 09:19:59 PDT
Thanks, Neil :)

I think this should be relnoted in 1.8, not just for new users, but also because
"old" users might notice, and finally be able to use the "Log Out" feature like
they first thought it would work.
Comment 112 Boris 'pi' Piwinger 2004-09-21 09:37:53 PDT
My understanding is that this patch does not fix the bug, but only logs out 
automatically after some time (fixed over all sites and situations). So you 
cannot say "I want to log out here and now."

Comment 113 Vidar Haarr (not reading bugmail) 2004-09-21 09:41:19 PDT
(In reply to comment #112)
> My understanding is that this patch does not fix the bug, but only logs out 
> automatically after some time (fixed over all sites and situations). So you 
> cannot say "I want to log out here and now."

No, it logs you out when you click the 'Log out' menuitem.
Comment 114 Mark Bitterling 2004-09-21 10:28:21 PDT
I am very happy to see the recent work that has been done, but I do not believe that this bug is 
completely fixed yet.

We now have the ability to logout without exiting the browser and restarting, but we do not yet have 
the ability to log out of a specific website without logging out of all websites as per the original 
description, Comment 1 , and Comment 15 by Boris.

Also mentioned in Comment 1, as well as subsequent comments, is the need/desire to enable web 
authors to access this site specific logout functionality via Javascript or some other mechanism.  It is my 
understanding from Comment 54 that Microsoft's Internet Explorer provides the ability to IE web 

I suggest reopening this bug.
Comment 115 Boris Zbarsky [:bz] 2004-09-21 10:50:08 PDT
Quite frankly, I no longer care about this bug (and haven't for years).  It's
unfortunate that I couldn't stop the bugspam, since I was the reporter.

Please put any further noise in separate bugs, for my sanity's sake...
Comment 116 Mark Bitterling 2004-09-21 12:00:23 PDT
Are you calling my post "bugspam" and "noise" ? 

Frankly your post is more characteristic of bugspam than mine.  Your post has absolutely nothing to do 
with the bug itself.  It is simply about your desire to disassociate with the bug.  My post was about the 
fact that the bug is not yet resolved.  If you feel a need to discuss this any further then email me 

Regardless of whether or not your interest in the bug as changed, the issue is still the same.  The bug 
was opened to address a specific issue which you had clearly identified and outlined in previous 
comments.  The recent patch does not address that issue.

I am sorry if Bugzilla does not allow you to remove your email address from the bug, but I do not see 
how that justifies closing the bug.  The patch does not fix the bug.

However, if you do not want to be on the mailing list then as a workaround for this Bugzilla failing, then 
someone should reopen one of the bugs that was closed as a dupe and close this one as a dupe of it.

Possible dupes to chose from : 
 Bug 238768
 Bug 233008
 Bug 253765
 Bug 238768

The way that I read it, these dupes all refer to the ability to logout of a specific website and thus they 
are not resolved by this patch which does not allow anyone to log out of a specific website.  
Comment 117 Daniel Veditz [:dveditz] 2004-09-21 12:08:34 PDT
Created bug 260839 to cover logging out of an individual site without logging
out of all.
Comment 118 James Sams 2004-09-21 12:22:27 PDT
not to add to the 'spam' of this bug, but I filed a separate bug, i cannot find
the number now, some time ago about being able to log out of mail (imap, smtp,
pop, etc) using the sign out feature. It was marked as a dupe of this, and my
understanding is that the patch does not fix the full behavior to be expected
(i.e. signing out signs out of websites as well as anything the mail client is
logged into).
Comment 119 benc 2005-01-12 04:50:27 PST
James: reopen the bug you filed.

Mark: bz has fixed a lot of bugs, and now he is suffering from the curse of the
reporter, bug 215588. Please be nice to him.

Vidar: can you send me steps on how this works? I'm using Mozilla 1.8a4 w/, and I can't get it to work.
Comment 120 Vidar Haarr (not reading bugmail) 2005-01-12 04:59:19 PST
(In reply to comment #119)
> Vidar: can you send me steps on how this works? I'm using Mozilla 1.8a4 w/
>, and I can't get it to work.

1. Open that URL in Mozilla
2. Log in with test/test
3. See that gemals page says "Your client supports HTTP Basic ..."
4. Refresh (Ctrl+R)
5. See that you are still logged in
6. Click Tools->Password Manager->Log out and OK in the dialog that pops up
7. Click Refresh (Ctrl+R) again.

You should be prompted to log in again.

Note You need to log in before you can comment on or make changes to this bug.