You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by pero <pe...@antaramusic.de> on 2001/09/17 03:26:08 UTC
form based login
Hi there,
I can't get the form based login-stuff working. I searched the Mailingslist,
but I found nothing that could help me.
First I have to say that the TC-example works... and THAT makes me dizzy :-)
my config:
TC4 RC2, using different CATALINA-HOME, Memory-Realm
server.xml
---------------------
<Engine ...>
...
<Realm className="org.apache.catalina.realm.MemoryRealm" />
...
<!-- perhaps important - using docBase="" -->
<Context path="" override="true" reloadable="false" cookies="false"
docBase="" debug="0"/>
</Engine>
---------------------
tomcat-users.xml
---------------------
<tomcat-users>
<user name="test" password="test" roles="admin" />
</tomcat-users>
---------------------
web-xml (in my webapp-home)
---------------------
<!-- protect admin stuff -->
<security-constraint>
<web-resource-collection>
<web-resource-name>admin</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/admin/login.jsp</form-login-page>
<form-error-page>/admin/loginerror.jsp</form-error-page>
</form-login-config>
</login-config>
---------------------
To avoid any mistyping I simply copied the login.jsp from the examples. When
I try to access a protected resource like
http://localhost/admin/some.jsp then the login.jsp is called (but TWICE, I
realized this after I put a "System.out.println" into
the login.jsp). When I type admin/admin then the login-page is called again.
Whenever I type an obviously wrong username/password combination
the loginerror.jsp is called.
While trying everything, I got it "so far" that it redirected to
http://localhost/admin/null. But I don't know what I did to get there (but I
think I could reproduce this case when it's late at night again and I am
completely tired :-)
I strongly believe that this is simply misconfiguration and that my failure
is clear to see (just not for me :-)
If someone could enlight me on that?
sincerly,
pero
RE: form based login
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 17 Sep 2001, pero wrote:
> Date: Mon, 17 Sep 2001 14:23:27 +0200
> From: pero <pe...@antaramusic.de>
> Reply-To: tomcat-user@jakarta.apache.org
> To: tomcat-user@jakarta.apache.org
> Subject: RE: form based login
>
> Hi Craig,
>
> thanks for your fast reply. To avoid any misunderstandings - my tomcat
> configuration works well (including sessions based on URL-rewriting) for my
> (not that small) application, I just wanted to protect the admin-stuff.
> I think your guess was right: Setting cookies to "true" solves this.
> Switching back to URL-rewriting doesn't work.
>
> If this is a bug, will it be fixed until the final release? (if not, I have
> to deal with it...)
>
OK, I figured out what was going on here.
Tomcat 4 is already performing URL rewriting on the redirects it does to
perform form-based login. However, it is also required that your form
login page must do URL rewriting on its own link -- otherwise, there is no
way to maintain session identity in the absence of cookies.
I solved this by modifying the <form> tag on my login page to say:
<form method="POST"
action='<%= response.encodeURL("j_security_check") %>'>
...
</form>
and everything worked correctly. I've just modified the form based login
example that will ship with Tomcat 4 to use this technique as well.
> thanks,
> pero
Craig
RE: form based login
Posted by pero <pe...@antaramusic.de>.
Hi Craig,
thanks for your fast reply. To avoid any misunderstandings - my tomcat
configuration works well (including sessions based on URL-rewriting) for my
(not that small) application, I just wanted to protect the admin-stuff.
I think your guess was right: Setting cookies to "true" solves this.
Switching back to URL-rewriting doesn't work.
If this is a bug, will it be fixed until the final release? (if not, I have
to deal with it...)
thanks,
pero
login from home page
Posted by Carlo Sorda <cs...@peoples.it>.
Hi,
I have this situation:
I have an Home Page, in my home page there are two text box for input login
and password.
What can I do for authenticate a user and go to a protect area.
My protect area is configured whit:
<login-config>
> <auth-method>FORM</auth-method>
> <form-login-config>
> <form-login-page>/admin/login.jsp</form-login-page>
> <form-error-page>/admin/loginerror.jsp</form-error-page>
> </form-login-config>
> </login-config>
When I direct go in http://localhost/admin/ my login.jsp appear and all OK,
but nothing do to when I insert name and password on my home page.
What can I do? There is a solution?
Thanks, Carlo Sorda
Re: form based login
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 17 Sep 2001, pero wrote:
> Date: Mon, 17 Sep 2001 03:26:08 +0200
> From: pero <pe...@antaramusic.de>
> Reply-To: tomcat-user@jakarta.apache.org
> To: tomcat-user@jakarta.apache.org
> Subject: form based login
>
> Hi there,
>
> I can't get the form based login-stuff working. I searched the Mailingslist,
> but I found nothing that could help me.
> First I have to say that the TC-example works... and THAT makes me dizzy :-)
>
> my config:
> TC4 RC2, using different CATALINA-HOME, Memory-Realm
> server.xml
> ---------------------
> <Engine ...>
> ...
> <Realm className="org.apache.catalina.realm.MemoryRealm" />
> ...
> <!-- perhaps important - using docBase="" -->
> <Context path="" override="true" reloadable="false" cookies="false"
> docBase="" debug="0"/>
>
Using a path of "" would be appropriate if you are talking about the ROOT
web application.
I assume that there is a <Host> element surrounding the <Context> as well?
Hmm, setting cookies to false means that cookies cannot be used for
session management -- yet form-based login requires sessions. Could you
do me a favor and try it with cookies="true" to see if that solves your
problem? In the mean time, I will look at the code to make sure it works
correctly in the "false" case.
> </Engine>
> ---------------------
>
> tomcat-users.xml
> ---------------------
> <tomcat-users>
> <user name="test" password="test" roles="admin" />
> </tomcat-users>
> ---------------------
>
> web-xml (in my webapp-home)
> ---------------------
> <!-- protect admin stuff -->
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>admin</web-resource-name>
> <url-pattern>/admin/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>admin</role-name>
> </auth-constraint>
> </security-constraint>
>
> <login-config>
> <auth-method>FORM</auth-method>
> <form-login-config>
> <form-login-page>/admin/login.jsp</form-login-page>
> <form-error-page>/admin/loginerror.jsp</form-error-page>
> </form-login-config>
> </login-config>
> ---------------------
>
> To avoid any mistyping I simply copied the login.jsp from the examples. When
> I try to access a protected resource like
> http://localhost/admin/some.jsp then the login.jsp is called (but TWICE, I
> realized this after I put a "System.out.println" into
> the login.jsp). When I type admin/admin then the login-page is called again.
> Whenever I type an obviously wrong username/password combination
> the loginerror.jsp is called.
> While trying everything, I got it "so far" that it redirected to
> http://localhost/admin/null. But I don't know what I did to get there (but I
> think I could reproduce this case when it's late at night again and I am
> completely tired :-)
>
>
> I strongly believe that this is simply misconfiguration and that my failure
> is clear to see (just not for me :-)
> If someone could enlight me on that?
>
> sincerly,
> pero
>
>
On the surface, this looks correct -- and I'm taking you at your word that
you are *not* trying to request the login page itself from the client,
right? If you did that, the behavior described would be correct since
you've got the login page inside the area protected by the security
constraint.
Please try also cookies="true" just to make sure that works for you. If
it does, but cookies="false" does not, we've just narrowed down to what
the problem is.
Craig