Closed
Bug 103402
Opened 23 years ago
Closed 23 years ago
HTTP authentication allows view of first page if previously authenticated
Categories
(Core :: Networking: HTTP, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: rocco_martin, Assigned: darin.moz)
References
Details
Tested on Build 2001091303. This problem shows up on our network management program which uses basic HTTP authentication on the root homepage. When I first visit the page, the authentication dialog comes up as expected. I then type in my username and password, then proceed on to view the reports. So far, so good. If I close the browser, launch another instance, and go back to that page I will be able to see the top level page with no authentication. I can also visit any pages that I had previously visited without being confronted with the authentication dialog. It is only when I try to view a page I haven't seen before that I am asked to provide my username/password. I expect a new instance of a browser to provide the authentication challenge immediately when I try to access that page. If I go to Edit|Preferences|Advanced|Cache and force the disk cache to clear before attempting to revisit the site, then I will properly get the authentication challenge. This behavior is in Netscape 6.1, and Mozilla 0.9.4. IE 5, 5.5, and 6 work correctly, as does Netscape 4.7. If necessary, I can probably set up an example. This may be related to Bug 96705.
Comment 1•23 years ago
|
||
*** Bug 103403 has been marked as a duplicate of this bug. ***
Comment 2•23 years ago
|
||
Reporter: Are you using fastload/turbo ?
Reporter | ||
Comment 3•23 years ago
|
||
Nope. I also verified that the "Enable Quick Launch" button in the preferences is unchecked.
Comment 4•23 years ago
|
||
What http headers are being sent? Unless the page says not to cache the data, we will save it in the cache for your profile. I suspect that that is why Actually, darin: Should authenticated data be memcache only? There are problems with wokring out exactly which urls needed the login which we sent.
Assignee | ||
Comment 5•23 years ago
|
||
yeah, a simple solution would be to make authenticated pages mem-cache only.
Assignee | ||
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
Assignee | ||
Comment 7•23 years ago
|
||
gordon, gagan: what do you think about this bug? at one time we did put authenticated content only in the memory cache. that changed when the http rewrite landed. ic two solutions: 1) if an URL was retrieved using an Authorization header, put the response in the memory cache. 2) if an URL was retrieved using an Authorization header, then set a flag in the meta data that would force a reload if the last fetched time is earlier than the session start time. solution 1 probably makes more sense from the pov of maximizing privacy, whereas the second tries to maximize benefits from caching.
Even though solution 1 makes sense I am concerned that if the web site(s) you are working on uses auth then you are pretty much ensuring that the cache is not reused :-( and this could be a problem. Additionally what about proxy authenticated pages? I'm thinking of another possible solution that uses a hash of the auth-string as a seed to generating the cache key. So if the login/passwd ever changes the keys would not match. So even though the content is cached (and rightly so becuz of the appropriate cache headers on the pages) its only available to the "right" user.
Assignee | ||
Comment 9•23 years ago
|
||
gagan and i discussed this some more and we concluded that we could get away with simply storing the Authorization header along with each cache entry. Upon reuse we'd always check that the auth cache has the authorization header value before reusing the cache entry. if the values don't match then we'd validate the cache entry with the server before reusing.
Status: NEW → ASSIGNED
Comment 10•23 years ago
|
||
How will this handle digest auth, where the entire authorization header isn't what is important? I suppose break it out into a function, or something. What about proxy auth?
Assignee | ||
Comment 11•23 years ago
|
||
bbaetz is right... we do need a better solution. with digest authentication the authorization header is not static.
Assignee | ||
Comment 12•23 years ago
|
||
-> 0.9.7, as it's unlikely this will make it for 0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Assignee | ||
Comment 13•23 years ago
|
||
-> 0.9.9 as there's a bunch of higher priority stuff
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 14•23 years ago
|
||
I would like to toss in my two cents on this and regard this bug as SERIOUS. Indeed, I found this bug when I was about to report it, because I (like many users I'm sure) did NOT see expected behavior when I closed all windows. It is a HUGE security concern when a user unwittingly expects that he has logged off from his bank site by closing all browser windows. The problem as I see it, is that when 'quick launch' is enabled, authentication tokens are cached. Conversly, most users expect that when they close all browser windows, they are effectively logged of from their athenticated site (auth. tokens are cleared from memory, in addition to non-persistent cookies). Summarily, I would at least hope to see a notice placed next to the prefs:UseQuickLanch option that states that closing all windows will NOT log you off, or better yet, two quick launch radio options; one that persists user auth/cookies, and one that doesnt. Even this is a potential problem, though, because users expect *consistent and obvious* behavior from installation to installation (without having to first verify a preference setting -that they may not even be familiar with). On a tangent thought, perhaps an even more prudent and useful feature would be a predominatly placed button on the toolbar that 'logs out' (clears) all temp cookies and authentication tokens for the current site. This sure beats having to close all windows, which has always been purely cumbersome as a 'logout' method. This 'logout button' could obviously also apply to other components of the suite, but I'd argue that it SHOULDNT, because too many browsers are used in a multi user enviroment, where users dont use any compnent of the suite other than the browser, and logout/login should be lightweight as possible (the whole browser interface shouldnt have to be restarted). To extend the usefulness of this concept further, we would ideally have a means whereby, when a user clicks on a 'logout' browsers button, the browser also as a coutesy request to some 'logout URL' from the host site, so that the site can record the logout and release its session attributes. Perhaps this 'logout URL' could be obtained/cached from a HTTP response header -or http body meta tag, from the host site's pages. Perhaps it could even be a new request type; LOGOUT HTTP1.1 I suppose a 're-login' URL should be returned from the server as well, so that the browser could be redirected to a login page (good for intranets). Returning to the original issue; what further compounds the WWW sites' logout-method uniformity problem is all the ambiguous numbers of ways different users have to logout from a site; -logout from their OS's GUI, -logout by closing all browser windows (and email in the case of NS/MOZ) -logout by clicking on a non-uniformly placed link on the current site -and, in the case of mozzilla, closing all windows AFTER verifying that quick lanch isnt running, which isnt the behavior that NS4/IE exhibit... a completly new consideration to remember. For these reasons I'd argue for *both* a 'suite logout' and the affrorementioned 'site logout' buttons on the toolbar. In the least, the 'site logout' should be very easy to implement, enless one feels ambitious enough to develop and implement the host-site logout courtesy notification protocol concept. ken
Assignee | ||
Comment 16•23 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•