DO NOT REPLY [Bug 3839] - Problem bookmarking login page

[bu...@apache.org]

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

kahroo@hot.ee changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|WONTFIX                     |



------- Additional Comments From kahroo@hot.ee  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org