tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name
Date Fri, 01 Nov 2002 10:47:54 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279

Resubmit to j_security_check mistakenly fetches a page of that name





------- Additional Comments From Brian.Ewins@btinternet.com  2002-11-01 10:47 -------
>This bug is still around in 4.1.12.

And its still not cleared up in the servlet 2.4 spec. I posted a comment on the
spec during the public review stage, and got this reply from Yutaka Yoshida:

>>Thank you for the feedback and I'm sorry for being so late
>>to get back to you. Issues you mentioned were actually
>>brought up in the expert group, and we'll try to put them
>>in to 2.4.
>>
>>again, thank you very much for the 'Suggested Resolution'

(The resolutions I suggested were that either a specific exception would be
thrown in this case, or that an additional standard parameter could be added to
the login forms to specify where the user should be taken when this bug occurs.
Another simple idea which involves no spec change is presented at the end of
this comment) Unfortunately, no change made it into the final draft.

>It is usually standard practice to post patches in unified diff format (diff -u).

I know - I really need to get into the habit of grabbing source and updating it
instead of just looking at cvs.apache.org :)

>My understanding of the problem is that:
>1. We want FormAuthenticator to mirror BasicAuthenticator as closely as 
> possible from the user's perspective.

That's what I'd like. One open concern is whether sessions should invalidate or
not when you provide new credentials. This isn't the case (to the best of my
knowledge) with either BASIC or DIGEST auth.

>2. In BASIC authentication, when a user successfully authenticates and presses
>the "back" button, the user is returned to the page she was on before
>attempting to access a secured resource.  If the attempt to access the secured
>resource is the very first page visited after opening a browser, then the
>"Back" button is unavailable.
>
>Number 2 is not reproducible using FormAuthenticator because an extra request
>is generated (the request for the login page).  Therefore we must decide on 
>a desired behavior for this scenario.  Any takers?"

My point is that you cant stop the user pressing the back button and seeing the
login form. RFC 2616, Section 13.13 "History Lists":

   History mechanisms and caches are different. In particular history
   mechanisms SHOULD NOT try to show a semantically transparent view
   of the current state of a resource. Rather, a history mechanism is
   meant to show exactly what the user saw at the time when the 
   resource was retrieved.

In other words, showing the login form when you click back is /exactly/ what
browsers are meant to do, and no amount of no-cache headers will help if the
browser follows the spec.

So, we have to deal with what happens when the user misuses the login form. One
thing that would help is if TC stopped using 'redirect' to take users to the
login form, and used a 'forward' instead! (this isn't a spec violation). This
would mean the URL of the login form would /never/ appear in the browser. Users
could bookmark the login page if they wanted, but since the bookmark would be
for http://some/webapp/secure/resource instead of for
http://some/webapp/login/page it wouldnt matter. 

The change there is much smaller than the stuff I suggested before - just to
change the line:
            hres.sendRedirect(hres.encodeRedirectURL(loginURI));
to something like 
            hreq.getRequestDispatcher(loginURI).forward(hreq,hres);

The only remaining problem would be what happens when the user clicks the back
button to see a login form. If we know we have used a forward instead of a
redirect, it becomes possible for TC to guess the page they were trying to log
in to from the REFERER header (since this will be the URL of the page that
caused the login screen to appear in the first place). Some users will be
blocking referer headers, but its better than the errors TC throws out right now.

The final issue to be resolved would be what to do with a session if someone
resubmits login credentials. My gut feeling is that if your principal changes
your session should be invalidated first, but this could be made an option in
server.xml. There is no spec to guide this issue.

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message