Closed Bug 55181 Opened 24 years ago Closed 20 years ago

Ability to log out of all sites using HTTP Basic authentication [forget/change/clear login info]

Categories

(Core :: Networking: HTTP, enhancement)

Product:
Core
Component:
Networking: HTTP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: vhaarr+bmo)

References

(Blocks 2 open bugs)

Details

(Keywords: arch, relnote)

Attachments

(2 files, 3 obsolete files)

debugging logs and a scenario where the current fix doesn't work
70.25 KB, application/octet-stream
Details
updated to darins comment 99 suggestions
1.78 KB, patch
neil
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review 
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
user.

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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
solution.

IMO: suggestion (1) is easy to do and would probably satisfy most users.
added keyword arch.
Keywords: arch
added RFE to summary.
Summary: A way to log out of sites that use BasicAuth → [RFE] A way to log out of sites that use BasicAuth
Blocks: 61681
about:logout may be the easiest solution. cc'ing conrad who also has an interest 
in this.
wouldn't about:http make more sense?  there could be a logout button with a
description of what this means.
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.

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.
> 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...

W3C `Common user agent problems' <http://www.w3.org/TR/2001/NOTE-cuap-20010206>, 
1.8: Provide a mechanism to allow authentication information to expire.
Blocks: 68427
Depends on: 68427
*** Bug 68409 has been marked as a duplicate of this bug. ***
No longer blocks: 68427
No longer depends on: 68427
Blocks: 68427
No longer blocks: 68427
Blocks: 68409
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 
separately. 
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.)

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.
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.
Target Milestone: --- → Future
neeti
Assignee: gagan → neeti
*** Bug 69011 has been marked as a duplicate of this bug. ***
mass move, v2.
qa to me.
QA Contact: tever → benc
Shouldn't we implement dropping auth values as part of the -turbo feature?
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.
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?domain=www.zope.org
?
about:logout could provide a list of domains and a button marked "Everything" or
whatever.

Gerv
Don't forget the realm.

about:logout?domain=www.zope.org+realm=Zope

or something similar...

Logout functionality is really the only reason I use that icky form-based
authentication -- because I can always destroy the cookie...
*** Bug 120092 has been marked as a duplicate of this bug. ***
*** Bug 129738 has been marked as a duplicate of this bug. ***
I see that there is not a Target Milestone set for this bug.  Is anyone working
on it, or is there help wanted?
Patches are always welcome !
Keywords: helpwanted
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.  :)
*** Bug 139888 has been marked as a duplicate of this bug. ***
*** Bug 139405 has been marked as a duplicate of this bug. ***
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
	session_unset();
	$acl = array('expired' => 2);
	session_register('acl');
	$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?
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
authentication.

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)
function:

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.
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 :-/
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.

Gerv
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:

about:logout?domain=foo.com:4444&realm=Wally%20World

reassigning to me.
Assignee: neeti → darin
about:http-logout might be better, or

about:http?action=logout&domain=xxx&realm=yyy

hmm...
Status: NEW → ASSIGNED
about:logout?protocol=http&domain=foo.com&... ?

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?

Gerv
yes, i think we could limit websites access to about:logout based on the URL's
hostname:port.

cc'ing mitch
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.
Okay, I'm all thoughtful today.  Sorry. :-)  But is about: really the correct
scheme for this?

A question, first: does Mozilla.org or Netscape have an RFC2717 tree for
defining new schemes?  Then, perhaps, something like
moz-logout:http/www.example.com?realm=Blah could work.

Or, perhaps (and I don't know how abusive this is, this isn't my favorite idea),
http://@www.example.com/ (null password) to log out?

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.
How about X-Logout:

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

Please look at bug 130089.
*** Bug 155811 has been marked as a duplicate of this bug. ***
*** Bug 157762 has been marked as a duplicate of this bug. ***
*** Bug 159045 has been marked as a duplicate of this bug. ***
*** Bug 160482 has been marked as a duplicate of this bug. ***
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.
Good point. Please file a bug in Password Manager for that, because it will
likely require separate code to implement.
-> HTTP
Component: Networking → Networking: HTTP
QA Contact: benc → tever
*** Bug 162051 has been marked as a duplicate of this bug. ***
*** Bug 171135 has been marked as a duplicate of this bug. ***
Summary: [RFE] A way to log out of sites that use BasicAuth → Ability to log out of sites using Basic Auth [forget HTTP authentication][change/clear login info]
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 ...
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....
no plans to freeze nsIHttpProtocolHandler anytime soon.
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.  ;)
Target Milestone: Future → mozilla1.4alpha
I agree with comment 46.

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.

http://groups.yahoo.com/group/rest-discuss/message/3407

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.
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).
nsIHttpAuthManager is coming online... see bug 60304.  it includes a ClearAll
method.  this could be used to expose this functionality via the UI.

-> future
Priority: P3 → P5
Target Milestone: mozilla1.4alpha → Future
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 :-)

Gerv
gerv,

see http://bugzilla.mozilla.org/attachment.cgi?id=117705&action=view .. 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.
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. :-)

Gerv
I think it's pretty important that we have something like:
ClearAuthenticationCache
command available via JavaScript

ala:
http://msdn.microsoft.com/workshop/author/dhtml/reference/constants/clearauthenticationcache.asp

having to guide users to some menu UI is also impossible.
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
date?  

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?
Blocks: 201620
No longer blocks: 201620
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.
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.

Gerv
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.
QA Contact: tever → httpqa
*** Bug 213203 has been marked as a duplicate of this bug. ***
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.
>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
>user.

>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
scenarios.
Hi, my name is Hugo, from Infohacking (www.infohacking.com). 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...?
Summary: Ability to log out of sites using Basic Auth [forget HTTP authentication][change/clear login info] → Ability to log out of sites using HTTP Basic authentication [forget/change/clear login info]
Extension utilising the new AuthManager API until real UI arrives:

http://mmcc.cx/mozilla/
*** Bug 233008 has been marked as a duplicate of this bug. ***
*** Bug 233044 has been marked as a duplicate of this bug. ***
*** Bug 235346 has been marked as a duplicate of this bug. ***
*** Bug 238768 has been marked as a duplicate of this bug. ***
the code from Clear HTTP Auth:
var isupports =
Components.classes['@mozilla.org/network/http-auth-manager;1'].getService()
var mHAService = isupports.QueryInterface(Components.interfaces.nsIHttpAuthManager)
mHAService.clearAll()

now we just need to add the menuitem and expose the function to JavaScript
*** Bug 253765 has been marked as a duplicate of this bug. ***
"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...
If it's not, let's see it, please.
Assignee: darin → david.balazic
Status: ASSIGNED → NEW
Priority: P5 → --
Target Milestone: Future → ---
Sounds to me like an ideal thing for an extension (and, in fact, I believe the
Web Developer Toolbar offers this functionality.)

Gerv
can we make password manager's log out feature clear http auth, too?
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.

pi
"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.

Gerv
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.
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.
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 ?


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:
<http://www.xiven.com/weblog/2004/07/24/UserAuthenticationOnTheWorldWideWeb#comments>
> 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.

Gerv
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?
Attachment #159068 - Flags: review?(neil.parkwaycc.co.uk)
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['@mozilla.org/network/http-auth-manager;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 ;-)
Attachment #159068 - Flags: review?(neil.parkwaycc.co.uk) → review-
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
bug.
Assignee: david.balazic → bugmail
Attachment #159068 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Comment on attachment 159143 [details] [diff] [review]
updated to neils comment 92 suggestions

Neil, could you review again, please?
Attachment #159143 - Flags: review?(neil.parkwaycc.co.uk)
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['@mozilla.org/network/http-auth-manager;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
lines.

>+      var wallet = Components.
>+            classes['@mozilla.org/wallet/wallet-service;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 ;-)
Attachment #159143 - Flags: review?(neil.parkwaycc.co.uk) → review+
>> 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.

pi
I've removed the walletPasswordExpire change and lined up the dots.
Attachment #159143 - Attachment is obsolete: true
Comment on attachment 159188 [details] [diff] [review]
updated to neils comment 95 suggestions

Carrying over r=neil.
Darin: could you sr, please?
Attachment #159188 - Flags: superreview?(darin)
Attachment #159188 - Flags: review+
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!)
Attachment #159188 - Flags: superreview?(darin) → superreview+
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.
>Does this bug also cover FireFox ?

no
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
interval.)

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).
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.
*** Bug 260186 has been marked as a duplicate of this bug. ***
Moved the httpAuthPasswordExpire() into expireHTTPAuthAndWallet() and also
cleaned up walletPasswordExpire()'s QI.
Attachment #159188 - Attachment is obsolete: true
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 ;)
Attachment #159459 - Flags: superreview?(darin)
Attachment #159459 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 159459 [details] [diff] [review]
updated to darins comment 99 suggestions

sr=darin provided Neil is happy with this patch.
Attachment #159459 - Flags: superreview?(darin) → superreview+
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 ;-)
Attachment #159459 - Flags: review?(neil.parkwaycc.co.uk) → review+
Fix checked in, without those lines :-)
Fix checked in, without those lines :-)
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Keywords: helpwanted → relnote
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."

pi
(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.
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 
developers.

I suggest reopening this bug.
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...
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 
directly.

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.  
Created bug 260839 to cover logging out of an individual site without logging
out of all.
Summary: Ability to log out of sites using HTTP Basic authentication [forget/change/clear login info] → Ability to log out of all sites using HTTP Basic authentication [forget/change/clear login info]
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).
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/
http://gemal.dk/browserspy/password-works.html, and I can't get it to work.
(In reply to comment #119)
> Vidar: can you send me steps on how this works? I'm using Mozilla 1.8a4 w/
> http://gemal.dk/browserspy/password-works.html, 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.
Blocks: 300002
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: