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 [EMAIL PROTECTED] 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>
