DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=3839>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=3839 Problem bookmarking login page [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2004-06-06 12:57 ------- First of all, I know that this FORM based authentication problem has been raised many times, but I really think that I have come up with a solution that would not violate the sun spec. The key to solving this problem is not to expose the login page URL to the user so it can't be bookmarked (the same goes for the error page URL). First the current flow with form based authentication: 1. Call the protected resource. (this is where the user context is saved) 2. Automatic outer forward to the custom login page. (this is the place where the users bookmark it) 3. Submit the login via j_security_check. (lets say the password was incorrect) 4. Automatic outer forward to the custom error page. (this page can also be bookmarked)(the steps 3 and 4 can be repeated many times). 5. Submit the login via j_security_check. (lets say that everything was OK) 6. Restore the original URL, delete the user context and do an aotomatic outer forward. As everybody can see the problem lies in the outer forwards to the "must be hidden" login and error page. Now concider the next flow that uses inner forwards instead. 1. Call the protected resource. (this is where the user context is saved) 2. Inner forward to the custom login page so the original URL stays in the browser. 3. Submit the login via j_security_check. (lets say the password was incorrect in which case we will save a marker to know that there was an error) 4. Now temporary recreate the original URL and do an automatic outer forward to it. As we saved a marker we won't do an inner forward to the login page anymore but to the error page. Additionally we delete the marker so that no other request gets it. 5. Submit the login via j_security_check. (lets say that everything was OK) 6. Restore the original URL, delete the user context and do an aotomatic outer forward. This new proposed solution has only two weak spots but these are unsignificant ones. 1. If the user happens to preform another separate call to the same protected resource in between the marker saveing and automatic outer forward returning then the error page will go to the wrong window. I also think it's impossible to happen in a real case. 2. The second problem is a bit bigger one. If the user will do a refresh to the login error page he will be taken to the login page instead. Now this behaviour would disturb me a lot if it weren't for the fact that usually you can't refresh form submits either plus this kind of action could also be concidered as a new request for the protected resource that it really is. As I know you all are a bit like me and won't accept the second point too easely because the fact remains that a refresh changes the users page. In that case it's possible to leave the error page logic like it works right now and hope that users don't want to bookmark error pages ;) (I myself think the refresh problem to be to small to allow users to bookmark wrong pages). Now I have just two more things to say. 1. If anybody thinks the marker can be preserved longer to fix the second problem please stop. Because a new horrible problem will arise when the user leaves our application without authorizeing and returns later to find an error page staring in his face (sessions, with the help of cokies, last a long time). 2. If anybody finds error in my reasoning please let me know but I'm sure that Tomcat can be the first web container to resolv this problem gracefully. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]