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)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
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.
*** Bug 103403 has been marked as a duplicate of this bug. ***
Reporter: Are you using fastload/turbo ?

Nope.  I also verified that the "Enable Quick Launch" button in the preferences 
is unchecked.
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.
yeah, a simple solution would be to make authenticated pages mem-cache only.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
-> me
Assignee: neeti → darin
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. 




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
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?
bbaetz is right... we do need a better solution.  with digest authentication the
authorization header is not static.
-> 0.9.7, as it's unlikely this will make it for 0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.7
-> 0.9.9 as there's a bunch of higher priority stuff
Target Milestone: mozilla0.9.7 → mozilla0.9.9
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
bug 96705 contains the fix for this bug :-)
Depends on: 96705
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified fixed.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.