This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm having a problem using Tomcat's FORM authentication method. I'm trying to use one JSP page as both the login page and the login error page. I set a session variable to control whether the login error message on the login page gets displayed.
This mostly works fine, until the very last step below:
The user tries to go to the webapp.
The user is shown the login page.
The user enters their user ID and password.
If the user mistypes their password, the login page is redisplayed with the error message visible. (Correct!)
After the user correctly enters their password, they get access to the webapp.
The user clicks the logout button.
The system displays the login page without the error message being shown. (Correct!)
The user closes their web browser and then opens it again.
The user tries to go to the webapp.
The user is shown the login page with the "login error" message being shown. (Incorrect!)
This is odd, since the error message should only be displayed if the session variable is set, and since the session was invalidated when they logged out, the session variable shouldn't still exist.
Here is part of web.xml:
Here is login.jsp:
In theory, when the user first tries to access the webapp and is given this page, the "retryLogin" session variable will not be "true", so the "login error" message will not be displayed. However, in the process of running this page, the session variable gets set. Therefore, if they mistype their user ID or password and this page is displayed again, then the <c:if> test will be true, so they will be shown the "login error" message.
Here is the bit of the HTML code that shows the logout button. It is present in all of the pages of the webapp:
Here is the logout.java code:
In theory, when the user clicks the "Logout" button in the webapp, this servlet will run and will invalidate the session. Therefore, if the "retryLogin" session variable was set earlier, this will cause it to go away, so that when they are shown the login page again, they won't see the "login error" message.
So... What would cause the <c:if> statement to be FALSE when the user logs out, but then become TRUE again after they've closed and reopened their web browser? [ October 11, 2005: Message edited by: Wally Hartshorn ]
Sooo if the solution could be to use differemnt login and loginError pages, why don't you try that? I'm not fond of using session valiables to hold state that isn't true for the life of the session eg maintaining state between two requests.
Joined: Jan 30, 2003
I didn't want separate login and error pages because it seems rather pointless to display a page that says, in effect, "you made a mistake, but you can't correct it on this page, you have to click 'Back' to take care of it." And although I could repeat the login form on the login-error page, that would mean duplicate HTML code -- not a huge deal, but if we change the appearance of the login page, we have to do so in 2 places.
My eventual solution was to create a form.jspf file that contains the actual login form, then have that JSP fragment included by both login.jsp and login-error.jsp.
I'm not 100% sure, but I think that perhaps the root cause of the problem might be related to the fact that it is an HTTPS connection. The user tries to connect via HTTP, Tomcat sees that it should be an HTTPS connection and instructs the browser to reconnect via HTTPS, the browser does so. I'm guessing that perhaps somewhere in that process the session variable winds up getting set, even though the user hasn't been present with the login form yet. Dunno.
In any case, this way works, but it involves 4 files (the *.jspf file, the 2 *.jsp files, and the *.css file that contains the styles I had to extract so that it could be shared by the 2 *.jsp files) rather than 1. Oh well.
[ October 13, 2005: Message edited by: Wally Hartshorn ] [ October 13, 2005: Message edited by: Wally Hartshorn ]