Redirect to the requested page failed using form-based authentication

[farag ahmed]

I have an application using tomcat server and java servlet. In my main page I enter string and submit it to the servlet. I wanted to make user authentication and therefore I used form-based authentication. I could successfully enter the user name and password. When the password is not correct I am directed to authentication based where it says login fails enter the usr name and password again. However, if the password and user name is correct I am not directed to the first jsp page I tried to access. Using basic authentication I have no problem I could enter user name and password and then I am directed to the first page I tried to access.

In order to implement this, I updated the web.xml:

<security-role>
<description>JSP view access</description>
<role-name>ab</role-name>
</security-role>

<security-constraint>
<web-resource-collection>
<web-resource-name>JSP pages</web-resource-name>
<!-- Protect every JSP page. -->
<url-pattern>*.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>

</web-resource-collection>
<!-- Specify the roles allowed to access these resources.-->
<auth-constraint>
<role-name>ab</role-name>
</auth-constraint>
</security-constraint>

<!--
Set up the pages to be displayed for login and error.
All accesses to pages in the webapp are redirected here.
-->
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/loginFailed.jsp</form-error-page>
</form-login-config>
</login-config>


Tomcat-user.xml:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="ab"/>
<user username="user" password="us" roles="ab"/>

</tomcat-users>

And in server.xml:

<Realm className="org.apache.catalina.realm.MemoryRealm" />

As I said with BASIC or DEGIST authentication it works fine. With form-based it seems to works but after the log in with the correct user name and password I am not directed to the requested page.

Thanks in advance

[Rob Spoor]

Are you using the right form action and name fields? They should be j_security_check for the form action and j_username and j_password for the username and password fields. See http://docs.oracle.com/javaee/1.4/tutorial/doc/Security5.html for more information.

[farag ahmed]

Rob Spoor wrote:Are you using the right form action and name fields? They should be j_security_check for the form action and j_username and j_password for the username and password fields. See http://docs.oracle.com/javaee/1.4/tutorial/doc/Security5.html for more information.

Thanks for your reply. Yes I am using them. As I mentioned when I enter false password or user name, I am notified. When I enter the correct user name and password no thing happened and I am not directed to the page I have been accessed before the security check.

any ideas?

[Tim Holloway]

Welcome to the JavaRanch, Faraq!

Regardless of which authentication scheme you wire into a J2EE webapp, the process is the same. When a user requests a protected URL (as defined by patterns in web.xml), the webapp server checks to see whether or not the user has already been authenticated. If so, the user's request proceeds.

If the user has not been authenticated, the user's URL request is placed "on hold", and the server's authentication processor takes over.

It is important to know that the authenticator is completely and entirely a process of the webapp server and its plug-in security (Realm) code. You cannot write a "login servlet" or servlet filter to participate in the authentication process. A lot of people fail to realize this, and think that just because their login page is a "jsp" that they can receive and process information at login time. The container will build the displayed login page using basic JSP processing, but the actual login processing is returned to a closed routine within the appserver itself whose sole function is to use the j_userid and j_password as arguments to the Realm's authenticate() method and instruct the Realm to set up a security context (UserPrincipal) if the Realm's authenticate() method returns "true".

Once authenticated, the original user URL request is taken "off hold" and processed as though the user had already been logged in. There are no events fired or other indications given to the webapp that login ever took place. Login is transparent. Therefore, you cannot know when a user has logged in and direct him/her to a specific login page. Which is actually good for those of us who like to form "bookmark" URLs that take us directly to secured functions within a webapp.

The other reason (besides bookmarkable secure URLs) that you don't get notified when a user logs in is that in the case of webapps secured with a Single Signon Realm, the actual login may have been done while working with an entirely different application, possibly on an entirely different server and even written in an entirely different programming language. All J2EE cares about is that whenever a user requests a secured URL, that URL is protected regardless of which direction the request came from or whatever other functions the user has been doing. This is critical, since one of the best ways to hack into a secured resource on a system that doesn't use the standard security system is to bypass the "normal" assumed processes.

[farag ahmed]

Tim Holloway wrote:Welcome to the JavaRanch, Farag!

Regardless of which authentication scheme you wire into a J2EE webapp, the process is the same. When a user requests a protected URL (as defined by patterns in web.xml), the webapp server checks to see whether or not the user has already been authenticated. If so, the user's request proceeds.

If the user has not been authenticated, the user's URL request is placed "on hold", and the server's authentication processor takes over.

It is important to know that the authenticator is completely and entirely a process of the webapp server and its plug-in security (Realm) code. You cannot write a "login servlet" or servlet filter to participate in the authentication process. A lot of people fail to realize this, and think that just because their login page is a "jsp" that they can receive and process information at login time. The container will build the displayed login page using basic JSP processing, but the actual login processing is returned to a closed routine within the appserver itself whose sole function is to use the j_userid and j_password as arguments to the Realm's authenticate() method and instruct the Realm to set up a security context (UserPrincipal) if the Realm's authenticate() method returns "true".

Once authenticated, the original user URL request is taken "off hold" and processed as though the user had already been logged in. There are no events fired or other indications given to the webapp that login ever took place. Login is transparent. Therefore, you cannot know when a user has logged in and direct him/her to a specific login page. Which is actually good for those of us who like to form "bookmark" URLs that take us directly to secured functions within a webapp.

The other reason (besides bookmarkable secure URLs) that you don't get notified when a user logs in is that in the case of webapps secured with a Single Signon Realm, the actual login may have been done while working with an entirely different application, possibly on an entirely different server and even written in an entirely different programming language. All J2EE cares about is that whenever a user requests a secured URL, that URL is protected regardless of which direction the request came from or whatever other functions the user has been doing. This is critical, since one of the best ways to hack into a secured resource on a system that doesn't use the standard security system is to bypass the "normal" assumed processes.

Thanks for your welcome words.
I agree with you. I am trying to do only what is doable based on the documentation and I am not trying to change any security roles.
My task is to force the user to login when he tries to access a jsp page. Using BASIC-authentication I have no problem, the user log in and access the page. The problem as I mentioned when I use FORM-based authentication the user tries to log in, if the user name or password is wrong a notification message appeared saying that the user name or password is wrong but if the user name and password is correct nothing happened. What I understood from the documentation is that when the log in is successful the user should be directed to the page he accessed before he was requested to log in or I missed something?
Where is the problem, why using FORM-based the user is not able to log in. My application is stand alone and I am working locally in my machine and not through network or so.

Any ideas
Farag

[Tim Holloway]

You have the right idea. Technically, you don't "have to force a log in", though, since when the user requests a protected URL, the webapp server will do the forcing without any action on your part. That's what makes it extra-secure. Do-it-Yourself security systems usually forget to force a login - especially after a few maintenance cycles, but the webapp server doesn't.

I use form-based authentication almost exclusively, and it does work exactly as you're expecting, which is to say the same response as you'd see from BASIC authentication.

If you provide us with a copy of your login page, we should be able to see what's wrong with it.

[farag ahmed]

Tim Holloway wrote:You have the right idea. Technically, you don't "have to force a log in", though, since when the user requests a protected URL, the webapp server will do the forcing without any action on your part. That's what makes it extra-secure. Do-it-Yourself security systems usually forget to force a login - especially after a few maintenance cycles, but the webapp server doesn't.

I use form-based authentication almost exclusively, and it does work exactly as you're expecting, which is to say the same response as you'd see from BASIC authentication.

If you provide us with a copy of your login page, we should be able to see what's wrong with it.

Hi;

Sorry I explained myself wrong. I don’t force the user, the webapp server force the user to log in before accessing secure webpage.

Here is the login.jap

<html> <head> <title>log in</title> <link rel="stylesheet" type="text/css" href="style.css"/> </head> <body> <%@ page contentType="text/html; charset=utf-8" session="true" %> <p> Enter user-ID und password: </p> <form method="POST" action='<%= response.encodeURL("j_security_check")%>' > <table border="0" > <tr> <th >User-ID:</th> <td ><input type="text" name="j_username"></td> </tr> <tr> <th >password:</th> <td ><input type="password" name="j_password"></td> </tr> <tr> <td ><input type="submit" value="Log In"></td> <td ><input type="reset"></td> </tr> </table> </form> </body> </html>

And here the loginFailed.jsp

<html> <head> <link rel="stylesheet" type="text/css" href="style.css"/> </head> <body> <%@ page contentType="text/html; charset=utf-8" session="true" %> <body> <p> the user name or password is not correct. please try again <a href='<%= response.encodeURL("dai-index.jsp") %>'>again</a>. </p> </body> </html>

[Tim Holloway]

OK.

The login page fails because the "action" isn't supposed to be an encoded URL. It should just be simply "j_security_check".

The loginfail page should have a login form, just like the login page, not a link or form action on it. In fact, I usually just clone my loginpage and put a "Login failed, please login" message on it. If you actually put an explicit navigation directive there, you'll effectively be abandoning the login process and you'll lose your original URL request.

[farag ahmed]

Tim Holloway wrote:OK.

The login page fails because the "action" isn't supposed to be an encoded URL. It should just be simply "j_security_check".

The loginfail page should have a login form, just like the login page, not a link or form action on it. In fact, I usually just clone my loginpage and put a "Login failed, please login" message on it. If you actually put an explicit navigation directive there, you'll effectively be abandoning the login process and you'll lose your original URL request.

Thanks for your reply. I changed it like this:

<form method="POST" action="j_security_check" >

then I got this error:

Error: Disconnected
The connection to the server was reset while the page is loaded.
if the user name or password is wrong, it notifies the user.

what is the problem here ?

Thanks

[Tim Holloway]

I'm not sure. However, I think your "page" JSP directive needs to be at the top. For one thing, content-type is an HTML header, and it usually causes an invalidstateexception when you try and set a header after you've already sent content.

[farag ahmed]

Tim Holloway wrote:I'm not sure. However, I think your "page" JSP directive needs to be at the top. For one thing, content-type is an HTML header, and it usually causes an invalidstateexception when you try and set a header after you've already sent content.

Unfortunately I still have the same problem.

might I did soem thing wrong,l here my tomcat-user.xml entries:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="admin"/>
<role rolename="role1"/>
<user username="test" password="fa" roles="role1"/>
<user username="role1" password="tomcat" roles="role1"/>
</tomcat-users>


here web-inf/my app/web.xml intries:

<security-role>
<role-name>role1</role-name>
</security-role>

<security-constraint>
<web-resource-collection>
<web-resource-name>management pages</web-resource-name>
<url-pattern>*.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>

</web-resource-collection>

<auth-constraint>
<role-name>role1</role-name>
</auth-constraint>

</security-constraint>

<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login/login.jsp</form-login-page>
<form-error-page>/login/loginFailed.jsp</form-error-page>
</form-login-config>
</login-config>

do you think all are ok here ?

[farag ahmed]

using Internet Explorer I got this error message:

HTTP Status 408 - The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser

--------------------------------------------------------------------------------

type Status report

message The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser

description The client did not produce a request within the time that the server was prepared to wait (The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser).


any idea ?

[Tim Holloway]

Probably you should set up your web.xml security rules so that the login/loginfail JSPs don't match any of the secured URLs. I think you're getting a infinite recursion on login. That is, in order to get to the login page, you have to be logged in, so it fetched the login page, but to access it you have to be logged in, and round and around and around!

[farag ahmed]

Tim Holloway wrote:Probably you should set up your web.xml security rules so that the login/loginfail JSPs don't match any of the secured URLs. I think you're getting a infinite recursion on login. That is, in order to get to the login page, you have to be logged in, so it fetched the login page, but to access it you have to be logged in, and round and around and around!

Hi,

I have now html login and faild log in pages but I still have the same problm. When I enter the user name and password I get this link "http://localhost:8080//myservlet/j_security_check". and this error "The connection to the server was reset while the page is loaded.".
Now I am suing basic auth with no problem but still very interested to make form auth. works.

here web.xml

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http:/java.sun.com/dtd/web-app_2_3.dtd">


<!-- Specify what is protected and who is allowed access. -->
<security-role>
<description>JSP view access</description>
<role-name>jspUser</role-name>
</security-role>

<security-constraint>
<web-resource-collection>
<web-resource-name>JSP pages</web-resource-name>
<!-- Protect every JSP page. -->
<url-pattern>*.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>

</web-resource-collection>
<!-- Specify the roles allowed to access these resources.-->
<auth-constraint>
<role-name>jspUser</role-name>
</auth-constraint>
</security-constraint>

<!--
Set up the pages to be displayed for login and error.
All accesses to pages in the webapp are redirected here.
-->
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/loginFailed.html</form-error-page>
</form-login-config>
</login-config>

<servlet>
<servlet-name>main</servlet-name>
<servlet-class>servlet.main</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>main</servlet-name>
<url-pattern>/main</url-pattern>
</servlet-mapping>


</web-app>

and

tomcat-user.xml


<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="jspUser"/>
<role rolename="ab"/>
<user username="test" password="tes" roles="jspUser"/>
</tomcat-users>

[Tim Holloway]

There's something odd here, but it's impossible to tell what it is. Check your Realm configuration and make sure that the login form isn't requesting secured resources or recursive resources.

[farag ahmed]

Tim Holloway wrote:There's something odd here, but it's impossible to tell what it is. Check your Realm configuration and make sure that the login form isn't requesting secured resources or recursive resources.

thanks i will check it carfuly soon.