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 16:51 ------- >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. I agree, and I think this means that we /can not/ replicate Basic Authentication's behavior here. We have to accept that Form Authentication differs in that it involves an extra page load on the client, thereby adding a page to the history. This happens whether we use a redirect or a forward. That said, I like the idea of giving the user the login form instead of the requested page without a redirect. Users can not bookmark a Basic Authentication login form, they must bookmark secured resources. This makes bookmarking work the same across Authenticator implementations. Also, I think the URI in the client for both items in the history will be the URI of the secured resource. So, pending some actual code to verify this, this might take care of the back button issue as well. On the session invalidation stuff, I think you're on to something. You should probably put it in another bug report as it can be addressed independently. -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
