On 10/11/12 17:47, Russ Kepler wrote:
On Saturday, November 10, 2012 05:14:43 PM you wrote:
I thought it would helpful to let you know that I am very nearly ready
to submitting a lot of new unit tests for the FormAuthenticator class.
The new tests explore url path extensions to carry the sessionid in the
absence of cookies.
I have a couple of cases left to develop, which are closely related to
your situation. If you are not in too much hurry, then I suggest you
wait for me, rather than waste time developing a demonstration war...
I'll get back to you later this week if I need any more information
about your problem, or even if I think you are just experiencing a
"that's just the way it works" situation (at the moment I am not sure).
Brian,
Thanks for the post, good to hear that my post hasn't been lost. I do have a
cheap test in a .war, attached. All it does is to try and get through the
form login. Form login works with cookie sessions but fails with URL
sessions. I've left commented out all the attempts to get past this in
login.jsp and in other files.
I really think the form login with URL validation got broken recently. I've
not been able to make it work with 7.0.32 but think it was working with an
earlier revision. I suspect that the combination of invalidating the original
session and creating a new one combined with losing the original requested URL
forces folks to simply cycle through j_security_check - if login fails it goes
to the error handler, if I pass it fails with a 408 because it's lost the
original URL. The same logic works when I change the tracking-mode from URL
to COOKIE; leading me to believe that I have things setup and it's some
breakage in authentication.
server.xml:
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
web.xml
<session-config>
<session-timeout>30</session-timeout>
<tracking-mode>URL</tracking-mode>
<!-- tracking-mode>COOKIE</tracking-mode -->
</session-config>
tomcat-users.xml:
<tomcat-users>
<role rolename="webtyper"/>
<user username="webtyper" password="webtyper" roles="webtyper"/>
</tomcat-users>
Russ,
Sorry about the delay.
I started to look at your demo war. Tomcat builds with a standard user
and role, so I decided to open your war and edit your web.xml to use
tomcat/tomcat.
I noticed that you have only one security constraint:
<security-constraint>
<web-resource-collection>
<web-resource-name>Typer</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>tomcat</role-name>
</auth-constraint>
</security-constraint>
That didn't look right to me, because you also have:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/logon.jsp</form-login-page>
<form-error-page>/logonError.jsp</form-error-page>
</form-login-config>
</login-config>
I /thought/ that meant an unauthenticated user does not have permission
to access your logon.jsp or logonError.jsp files. I have always included
an explicit "allow unauthenticated users" security constraint for those
pages in my own web.xml files.
HOWEVER, I WAS WRONG! When I followed your webapp through the
FormAuthenticator I discovered the forwardToLoginPage and
forwardToErrorPage methods do not make any reference to the security
constraints for the webapp. i.e. the form-login-config pages are
automatically accessible to unauthenticated users. (Thanks for giving me
the opportunity to learn something new!)
Once I had your with-cookies demo working properly, I then added the
session-config section with a tracking-mode of URL to your web.xml. I
was lazy and didn't use a stable tomcat release - I just ran it under my
current version of the trunk, which is deliberately a couple of weeks
back-level. I was very surprised to find that pressing the submit button
with a good username and password threw the browser out with a
connection reset!
I little bit of debugging and I discovered that authentication was
looping - each time j_security_check authenticated ok, but the session
created by the original HTTP GET to your protected resource was not
being recovered from the cache.
The line in your logon.jsp:
<form action="j_security_check" method=post >
... was the cause of the loop. I replaced it with:
<form method="POST" action='<%= response.encodeURL("j_security_check") %>' >
... and the logon was successful. This is because the browser will now
POST the FORM with a url path parameter which encodes the correct
jsessionid value.
This issue was discussed at length on the users mailing list under this
topic: "AuthenticatorBase setChangeSessionIdOnAuthentication without
cookies"
http://mail-archives.apache.org/mod_mbox/tomcat-users/201209.mbox/%3c505eda87.1080...@pingtoo.com%3E
Authenticated access to restricted resources can only happen if the
browser tells tomcat the session id when it requests ANY of those
restricted resources. This is usually done via cookies, but when cookies
are turned off the webapp has to keep reminding the browser of the
session id - especially if the default behaviour is being used by the
Container, when the session id is deliberately changed after authentication.
Your protected jsp's MUST ALL use response.encodeURL() if you want your
webapp to work properly without cookies.
Note to self: is my observed j_security_check loop an artefact of my
improperly updated sandbox, or is there a bug? I will try to add a
specific unit test to explore this behaviour soon.
As you can tell I'm not a regular user of Tomcat. That plus the issues in
Eclipse (I've got 3 versions of Juno and they all f'up web stuff in different
ways) I'm not completely sure of just where my problems are - Tomcat
(&friends) Eclipse or me. All I really want to do is to validate users on the
web & launch the Java Web Start (working without authentication) or validate
when the java code is directly executed. I didn't expect to spend weeks on
this (actually hours of frustration followed by days of ennui).
-- Russ
When using an IDE you need to be careful of classloader issues. Tomcat's
classloader environment is sophisticated and I sometimes encounter
strange behaviour under netbeans because it tries to cache classes for
speed, but this sometimes means my changes do not seem to have worked.
This can always be proved by restarting netbeans.
I don't use eclipse, so I can't comment on your specific problems.
However, you can simplify your debugging by running tomcat standalone
and attaching your debugger to it.
Regards,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
