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)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
People
(Reporter: bzbarsky, Assigned: vhaarr+bmo)
References
(Blocks 2 open bugs)
Details
(Keywords: arch, relnote)
Attachments
(2 files, 3 obsolete files)
(deleted),
application/octet-stream
|
Details | |
(deleted),
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.
Reporter | ||
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
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
about:logout may be the easiest solution. cc'ing conrad who also has an interest
in this.
Comment 6•24 years ago
|
||
wouldn't about:http make more sense? there could be a logout button with a
description of what this means.
Comment 7•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
> 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•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
*** Bug 68409 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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•24 years ago
|
||
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.
Reporter | ||
Comment 15•24 years ago
|
||
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 17•24 years ago
|
||
*** Bug 69011 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
Shouldn't we implement dropping auth values as part of the -turbo feature?
Comment 20•24 years ago
|
||
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•23 years ago
|
||
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
Comment 22•23 years ago
|
||
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...
Comment 23•23 years ago
|
||
*** Bug 120092 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
*** Bug 129738 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
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•23 years ago
|
||
Patches are always welcome !
Updated•23 years ago
|
Keywords: helpwanted
Comment 27•23 years ago
|
||
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. :)
Reporter | ||
Comment 28•23 years ago
|
||
*** Bug 139888 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
*** Bug 139405 has been marked as a duplicate of this bug. ***
Comment 30•23 years ago
|
||
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?
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
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•23 years ago
|
||
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
Comment 34•23 years ago
|
||
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
Comment 35•23 years ago
|
||
about:http-logout might be better, or
about:http?action=logout&domain=xxx&realm=yyy
hmm...
Status: NEW → ASSIGNED
Comment 36•23 years ago
|
||
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
Comment 37•23 years ago
|
||
yes, i think we could limit websites access to about:logout based on the URL's
hostname:port.
cc'ing mitch
Comment 38•23 years ago
|
||
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•23 years ago
|
||
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?
Comment 40•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 155811 has been marked as a duplicate of this bug. ***
Comment 43•23 years ago
|
||
*** Bug 157762 has been marked as a duplicate of this bug. ***
Comment 44•23 years ago
|
||
*** Bug 159045 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
*** Bug 160482 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
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•23 years ago
|
||
Good point. Please file a bug in Password Manager for that, because it will
likely require separate code to implement.
Reporter | ||
Comment 49•23 years ago
|
||
*** Bug 162051 has been marked as a duplicate of this bug. ***
Comment 50•22 years ago
|
||
*** Bug 171135 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
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]
Comment 51•22 years ago
|
||
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 ...
Reporter | ||
Comment 52•22 years ago
|
||
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•22 years ago
|
||
no plans to freeze nsIHttpProtocolHandler anytime soon.
Comment 54•22 years ago
|
||
IE has this:
http://msdn.microsoft.com/workshop/author/dhtml/reference/constants/clearauthenticationcache.asp
Can be tested at:
http://gemal.dk/browserspy/password-works.html login in with:
login: test
passwd: test
Reporter | ||
Comment 55•22 years ago
|
||
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. ;)
Updated•22 years ago
|
Target Milestone: Future → mozilla1.4alpha
Comment 56•22 years ago
|
||
I agree with comment 46.
Comment 57•22 years ago
|
||
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
Comment 58•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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
Comment 61•22 years ago
|
||
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
Comment 62•22 years ago
|
||
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.
Comment 63•22 years ago
|
||
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
Comment 64•22 years ago
|
||
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.
Comment 65•22 years ago
|
||
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?
Comment 66•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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
Comment 69•22 years ago
|
||
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
Comment 70•22 years ago
|
||
*** Bug 213203 has been marked as a duplicate of this bug. ***
Comment 71•22 years ago
|
||
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•22 years ago
|
||
>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...?
Updated•21 years ago
|
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]
Comment 73•21 years ago
|
||
Extension utilising the new AuthManager API until real UI arrives:
http://mmcc.cx/mozilla/
Comment 74•21 years ago
|
||
*** Bug 233008 has been marked as a duplicate of this bug. ***
Comment 75•21 years ago
|
||
*** Bug 233044 has been marked as a duplicate of this bug. ***
Comment 76•21 years ago
|
||
*** Bug 235346 has been marked as a duplicate of this bug. ***
Comment 77•21 years ago
|
||
*** Bug 238768 has been marked as a duplicate of this bug. ***
Comment 78•21 years ago
|
||
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
Comment 79•21 years ago
|
||
*** Bug 253765 has been marked as a duplicate of this bug. ***
Comment 80•20 years ago
|
||
"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...
Reporter | ||
Comment 81•20 years ago
|
||
If it's not, let's see it, please.
Assignee: darin → david.balazic
Status: ASSIGNED → NEW
Priority: P5 → --
Target Milestone: Future → ---
Comment 82•20 years ago
|
||
Sounds to me like an ideal thing for an extension (and, in fact, I believe the
Web Developer Toolbar offers this functionality.)
Gerv
Comment 83•20 years ago
|
||
can we make password manager's log out feature clear http auth, too?
Comment 84•20 years ago
|
||
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
Comment 85•20 years ago
|
||
"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
Comment 86•20 years ago
|
||
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.
Assignee | ||
Comment 87•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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>
Comment 90•20 years ago
|
||
> 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
Assignee | ||
Comment 91•20 years ago
|
||
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 92•20 years ago
|
||
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-
Assignee | ||
Comment 93•20 years ago
|
||
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
Assignee | ||
Comment 94•20 years ago
|
||
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 95•20 years ago
|
||
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+
Comment 96•20 years ago
|
||
>> 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
Assignee | ||
Comment 97•20 years ago
|
||
I've removed the walletPasswordExpire change and lined up the dots.
Attachment #159143 -
Attachment is obsolete: true
Assignee | ||
Comment 98•20 years ago
|
||
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 99•20 years ago
|
||
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+
Comment 100•20 years ago
|
||
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•20 years ago
|
||
>Does this bug also cover FireFox ?
no
Comment 102•20 years ago
|
||
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).
Comment 103•20 years ago
|
||
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•20 years ago
|
||
*** Bug 260186 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 105•20 years ago
|
||
Moved the httpAuthPasswordExpire() into expireHTTPAuthAndWallet() and also
cleaned up walletPasswordExpire()'s QI.
Attachment #159188 -
Attachment is obsolete: true
Assignee | ||
Comment 106•20 years ago
|
||
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 107•20 years ago
|
||
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 108•20 years ago
|
||
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+
Comment 109•20 years ago
|
||
Fix checked in, without those lines :-)
Comment 110•20 years ago
|
||
Fix checked in, without those lines :-)
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 111•20 years ago
|
||
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
Comment 112•20 years ago
|
||
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
Assignee | ||
Comment 113•20 years ago
|
||
(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•20 years ago
|
||
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.
Reporter | ||
Comment 115•20 years ago
|
||
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•20 years ago
|
||
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.
Comment 117•20 years ago
|
||
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]
Comment 118•20 years ago
|
||
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•20 years ago
|
||
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.
Assignee | ||
Comment 120•20 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•