Bug 23887 - FORM-based login with SSL broken in Mozilla (but not IE6)
Summary: FORM-based login with SSL broken in Mozilla (but not IE6)
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Unknown (show other bugs)
Version: 5.0.12
Hardware: PC Linux
: P3 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2003-10-17 10:19 UTC by Adam Hardy
Modified: 2004-11-16 19:05 UTC (History)
0 users

deployment descriptor (3.80 KB, text/plain)
2003-10-17 10:20 UTC, Adam Hardy
test.war (861.95 KB, application/octet-stream)
2003-10-17 10:22 UTC, Adam Hardy

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Hardy 2003-10-17 10:19:44 UTC
I cannot log in to an SSL-encrypted page with Mozilla. 

Tomcat just redisplays the login page continually and then perhaps after 5, 10
or 30 login attempts, it succeeds. 

Sometimes, at undefined times as far as my testing goes, it throws a status 400
'invalid direct reference to j_security_check' error.

I will attach a simple WAR to demonstrate. The web.xml is configured to work
with the TC memory realm. 

I will also attach just the web.xml for people who only want to do a quick check.

Best regards,
Comment 1 Adam Hardy 2003-10-17 10:20:42 UTC
Created attachment 8605 [details]
deployment descriptor
Comment 2 Adam Hardy 2003-10-17 10:22:00 UTC
Created attachment 8606 [details]
Comment 3 Remy Maucherat 2003-10-17 12:34:54 UTC
Mozilla is buggy: its cache handling is invalid (hint: hit refresh after logging
in). Please do not reopen the report unless you can prove bad behavior on the
Tomcat side (ex: bad redirects, bad session handling).
Comment 4 Adam Hardy 2003-10-17 17:58:44 UTC
Yes that is the problem. I've been tricked by the cache again. Caching is the
one of my biggest sources of wasted time in looking for bugs that aren't there. 

In the upgrade from TC4 to TC5, the URL of the FORM-based login page is hidden,
so I am not surprised by Mozilla's behaviour. I do not think Mozilla is buggy -
it is more likely a feature. :)

I was also caught out because I am using struts so much and the struts servlet
puts the non-cache headers in automatically if you configure it to do so.
Obviously these are not going to be taken care of in the HTML login page. 

So a refresh is all that is required. Or for anyone else reading this
afterwards, the following headers in the HTML (where the expiry date is in the
past) (check the source HTML if you can't see this):

<meta http-equiv="cache-control" content="public">
<meta http-equiv="expires" content="Fri, 30 Oct 2002 14:19:41 GMT">
<meta http-equiv="pragma" content="no-cache">

Comment 5 Remy Maucherat 2003-10-17 18:08:18 UTC
No, it's a Mozilla bug: Tomcat doesn't include a if-modified-since, and it is a
secure connection, so it is wrong to cache this. BTW, if this is not a secure
connection, Tomcat should set the appropriate cache control headers.
Comment 6 Adam Hardy 2003-10-17 18:19:11 UTC
OK I'll take your word for it. I'll log this at bugzilla.mozilla.org and let
them think about it. 

Thanks for the information.