Bug 43687 - after repeated authentication tomcat again sends page with login form instead of protected static resource
after repeated authentication tomcat again sends page with login form instead...
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
6.0.14
Other All
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-10-24 03:58 UTC by Przemyslaw Madzik
Modified: 2007-11-28 20:30 UTC (History)
0 users



Attachments
web app with form-based authentication (2.40 KB, application/octet-stream)
2007-10-24 04:01 UTC, Przemyslaw Madzik
Details
Patch so that complient browsers don't think the login page is the real page (1.14 KB, patch)
2007-10-25 19:20 UTC, william.barker
Details | Diff
Attempt to get around FireFox's aggressive caching (1.04 KB, patch)
2007-10-29 19:34 UTC, william.barker
Details | Diff
Patch to disable conditionals headers on a replay for Form Auth (1.29 KB, patch)
2007-10-30 20:11 UTC, william.barker
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Przemyslaw Madzik 2007-10-24 03:58:50 UTC
Steps to replicate problem:

   1) clear firefox cache
   2) load url "http://localhost:8080/aaa/index.html"
   3) fill in auth form
   4) on index.html page click logout link to logout.jsp (invalidate session and
redirect to index.html)
   5) fill in auth form
   6) you will get form page again (!)
   7) click "reload" button
   8) you will get index.html


Conversation with server:

firefox:  GET /aaa/index.html HTTP/1.1
 tomcat:  HTTP/1.1 200 OK
          ETag: W/"478-1193216820000"
          Last-Modified: Wed, 24 Oct 2007 09:07:00 GMT

          <page with login form>

firefox:  POST /aaa/j_security_check HTTP/1.1
 tomcat:  HTTP/1.1 302 Moved Temporarily
          Location: http://localhost:8080/aaa/index.html

firefox:  GET /aaa/index.html HTTP/1.1
          If-Modified-Since: Wed, 24 Oct 2007 09:07:00 GMT
          If-None-Match: W/"478-1193216820000"
 tomcat:  HTTP/1.1 200 OK
          ETag: W/"316-1193222364000"
          Last-Modified: Wed, 24 Oct 2007 10:39:24 GMT
          
          <page with protected content -- index.html>

firefox:  GET /aaa/logout.jsp HTTP/1.1
 tomcat:  HTTP/1.1 302 Moved Temporarily
          Location: http://localhost:8080/aaa/index.html

firefox:  GET /aaa/index.html HTTP/1.1
          If-Modified-Since: Wed, 24 Oct 2007 10:39:24 GMT
          If-None-Match: W/"316-1193222364000"
 tomcat:  HTTP/1.1 200 OK
          ETag: W/"478-1193216820000"
          Last-Modified: Wed, 24 Oct 2007 09:07:00 GMT
          <page with login form>

firefox:  POST /aaa/j_security_check HTTP/1.1
 tomcat:  HTTP/1.1 302 Moved Temporarily
          Location: http://localhost:8080/aaa/index.html

firefox:  GET /aaa/index.html HTTP/1.1
          If-Modified-Since: Wed, 24 Oct 2007 09:07:00 GMT
          If-None-Match: W/"478-1193216820000"
 tomcat:  HTTP/1.1 304 Not Modified
          ETag: W/"316-1193222364000"

firefox:  GET /aaa/index.html HTTP/1.1
          If-Modified-Since: Wed, 24 Oct 2007 09:07:00 GMT
          If-None-Match: W/"478-1193216820000"
          Cache-Control: max-age=0
 tomcat:  HTTP/1.1 200 OK
          ETag: W/"316-1193222364000"
          Last-Modified: Wed, 24 Oct 2007 10:39:24 GMT

          <page with protected content -- index.html>
Comment 1 Przemyslaw Madzik 2007-10-24 04:01:37 UTC
Created attachment 21032 [details]
web app with form-based authentication

war to reproduce described behaviour
Comment 2 Przemyslaw Madzik 2007-10-24 04:09:02 UTC
Comment on attachment 21032 [details]
web app with form-based authentication

war to reproduce described behaviour.

You need also configured user with role "aaa". It is my
$CATALINA_HOME/conf/tomcat-users.xml:
<?xml version='1.0' encoding='utf-8'?>					        
<tomcat-users>								        
  <role rolename="aaa"/>						        
  <user username="aaa" password="aaa" roles="aaa"/>			        
</tomcat-users>
Comment 3 Przemyslaw Madzik 2007-10-25 00:43:57 UTC
After looking a bit into source i found (FormAuthenticator.java) save/restore
mechanism for requests done before/after authentication. I don't understand
needs for it, particularly for save/restore ALL request headers. IMHO restoring
headers like "If-None-Match" is incorrect.

After commenting out lines  (403-412) which serve to restore request headers
problem not occurs.
Comment 4 william.barker 2007-10-25 19:20:51 UTC
Created attachment 21046 [details]
Patch so that complient browsers don't think the login page is the real page

Tomcat needs to replay the original request exactly to have any hope of
working.  This patch, against 6.0 trunk, should prevent any modern browser
confusing the login page with the actual resource that it requested.
Comment 5 william.barker 2007-10-25 19:31:21 UTC
(In reply to comment #4)
> Created an attachment (id=21046) [edit]
> Patch so that complient browsers don't think the login page is the real page
> Tomcat needs to replay the original request exactly to have any hope of
> working.  This patch, against 6.0 trunk, should prevent any modern browser
> confusing the login page with the actual resource that it requested.

Ok, so I'm having a brain-dead moment (seem to be pretty common around 
here :).  This patch should do nothing at all, and it is a FireFox bug that 
you are looking at (it shouldn't be sending 'if-modified-since' and 'if-none-
match' headers, since it was already told that the page is uncachable).
Comment 6 Przemyslaw Madzik 2007-10-29 00:47:40 UTC
(In reply to comment #5)
> Ok, so I'm having a brain-dead moment (seem to be pretty common around 
> here :).  This patch should do nothing at all, and it is a FireFox bug that 
> you are looking at (it shouldn't be sending 'if-modified-since' and 'if-none-
> match' headers, since it was already told that the page is uncachable).

IMHO it isn't firefox bug. RFC2616 (14.9.1 What is Cacheable) about
"Cache-control: no-cache" says:

    If the no-cache directive does not specify a field-name, then a
    cache MUST NOT use the response to satisfy a subsequent request
    without successful revalidation with the origin server. This
    allows an origin server to prevent caching even by caches that
    have been configured to return stale responses to client requests.

So because tomcat sends for static resources "ETag" and "Last-Modified"
headers it allow to make REVALIDATION by firefox.
Comment 7 william.barker 2007-10-29 19:34:55 UTC
Created attachment 21057 [details]
Attempt to get around FireFox's aggressive caching

From my reading of RFC 2616, this should work, since FF won't attempt to
revalidate a page that it doesn't have in it's cache.  If it doesn't work, than
I consider it an FF bug (since the login page isn't in it's cache from 2616).
Comment 8 Przemyslaw Madzik 2007-10-30 02:28:15 UTC
(In reply to comment #7)
> From my reading of RFC 2616, this should work, since FF won't attempt to
> revalidate a page that it doesn't have in it's cache.  If it doesn't work, than
> I consider it an FF bug (since the login page isn't in it's cache from 2616).

IMHO acording to RFC2616 (14.9.2) "Cache-control: no-store" header not clearly
forbids caching response in VOLATILE storage such as memory.

My understanding RFC2616 is following: to make response uncachable one should
send "Cache-control: no-cache" and NOT send headers used for revalidation such
"Etag" and "Last-Modified".

But the problem is IMHO in save/restore mechanism.
Comment 9 william.barker 2007-10-30 20:11:47 UTC
Created attachment 21063 [details]
Patch to disable conditionals headers on a replay for Form Auth

Ok, I'm convinced that it needs to be done in the replay.  

If you are able to actually try out this patch, and post here, it will probably
speed up getting it into the 6.0 tree.
Comment 10 Przemyslaw Madzik 2007-10-31 12:39:45 UTC
(In reply to comment #9)
> If you are able to actually try out this patch, and post here, it will probably
> speed up getting it into the 6.0 tree.

Patch is working for me. Thanks.
Comment 11 william.barker 2007-11-28 20:30:10 UTC
The patch has now been committed to SVN, and will appear in the next version 
of TC 6.x.