96705 - [zope] authentication should invalidate cache

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Matt Behrens]

Tested on 2001081710.

This problem manifests itself with a web site I'm designing with Zope
(http://www.zope.org/).  Zope defaults to using basic authentication.

When you first access the site, you are classified as "Anonymous" because you
are not sending any authentication.  Pages are cached appropriately.

The first time you access a resource that requires authorization, Zope asks Moz
to authenticate itself with basic authentication.  The user enters the username
and password, and said username and password are sent with further requests to
that site as well.

The problem: pages you have already visisted as an anonymous user are in cache
now.  If you try to reload them, the page is re-requested anonymously.

Expected behavior (IMO) would be that if you used the Back button to return to
the page, nothing would change; however if you clicked a hyperlink to go to a
page you've already visited, or if you clicked reload on a page, then your
credentials would be sent, allowing the server to generate a new page.

MSIE 5.00.3315.1000 (as included with Win2k) does not manifest this problem. 
Neither does Communicator 4.76.

I can probably set up a test case if this is not clear.

Comment 1

[gordon]

Interesting problem.  Not sure nsCacheService is the right place to fix this -
it doesn't know anything about authentification.  HTTP might be able to help,
but we don't want to invalidate everything in the cache.  I imagine that ImgLib,
and possible the parser will need to be involved as well.

Comment 2

[Darin Fisher]

reporter: how important is it to get this right for images?

Comment 3

[Matt Behrens]

I certainly don't dynamically generate any images based on authentication,
although for correctness it should be fixed there as well.

I personally would be happy with a fix that doesn't care about images though.

Comment 4

[Matt Behrens]

A little more info to puzzle over.

A workaround can be had by throwing "Pragma: no-cache" into the HTTP headers. 
This slows my intranet down a bit tho, as you might imagine.

Interestingly enough, clearing memory and disk caches do nothing to work around
this, though closing and reopening Moz do.  So maybe it isn't a cache deal after
all, but rather that somewhere further on up the line, the old page is still
being asked for?  I don't know a lot about Moz design so I just may be spouting
off here.

Comment 5

[Matt Behrens]

I can't repro this on 20010827.  Errr... I'm confused. :-)

Marking WFM unless this reappears...

Comment 6

[Matt Behrens]

Okay, I was mistaken.  I was testing two different things.

The following works:

1.  Go to the root page of the site.
2.  Hit the login link (which leads to a page that requires basic auth).
3.  Log in, and see the "logged in" page.
4.  Return to the root page.  The root page is requested again with the new
credentials.

The following does not:

1.  Go to the root page of the site.
2.  Go to another page on the site.
3.  Hit the login link, log in.
4.  Return to the page in step 2.  Said page is not requested with the new
credentials, even if Reload is hit.
5.  Return to the root page.  Same problem as step 4.

Sorry for the bug bouncing. :-)

Comment 7

[Darin Fisher]

hmm... we should be able to easily fix the reload case.

Comment 8

[Matt Behrens]

I'd say that's good enough.

Incidentally, I assume this is known already, but HTTP/1.1 says

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge.

I put my login page in the root of the web site to cover this case, and the
problem was still there with Moz.  (A related problem with MSIE went away though.)

Comment 9

[gordon]

Darin, do you want this one?

Comment 10

[Darin Fisher]

-> 0.9.9

Comment 11

[Darin Fisher]

*** Bug 122341 has been marked as a duplicate of this bug. ***

Comment 12

[Yuan-Chen Cheng]

I find a interesting way to produce this bug.

I start a zope web server that listen both to port
80 and 8080 (with one same content). The port 80
work fine, but the port 8080 has this bug.

Hope this helps.

Comment 13

[Matt Behrens]

[e-mail],

I am using port 80 when I have my problems, so I doubt that's the case.

Comment 14

[Darin Fisher]

i can solve this bug for the case in which the login page is found at the root
URL... eg. something like http://host/root/login.html

then everything under /root/ that was previously cached w/o authentication will
be re-requested with authentication after the user successfully logs in.

this seems like the valid setup that should force cached pages to be ignored.

patch-in-hand

Comment 15

[Darin Fisher]

Attachment: v1.0 patch

tested this patch w/ a zope-ish apache setup

  /root/login.html
  /root/subdir/

in my testcase, only login.html requires authentication.  i did the following
to test this patch:

1) goto /root/subdir/
2) goto /root/login.html
3) enter username:password
4) goto /root/subdir/

w/o the patch, the 4th step produces no network traffic.  w/ the patch, the 4th
step produces network traffic w/ authorization headers present.

this patch also fixes bug 103402.  to test that, i did the following test:

1) visit /root/login.html
2) close browser
3) visit /root/login.html

w/o the patch, the 3rd step produces no network traffic.  w/ the patch, the 3rd
step produces network traffic w/o authorization headers (auth cache is not
persistent across sessions).

i'll be marking bug 103402 dependent on this one since this patch contains both
fixes.

Comment 16

[Gagan]

Comment on attachment 68492 [details] [diff] [review]
v1.0 patch

r=gagan

Comment 17

[Scott MacGregor]

Comment on attachment 68492 [details] [diff] [review]
v1.0 patch

sr=mscott

Comment 18

[Darin Fisher]

fixed-on-trunk