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.
Thanks. I appreciate you providing more details before I got round to
asking!
FormAuthenticator and its super class, Authenticator, continue to
surprise me with wrinkles every time I step through them with a debugger.
I'm not going to speculate further about your problem at this stage,
because that could simply lay down trails of red herrings. However, my
own interest is in a similar-sounding, rare and as-yet-unreproducible
problem that a) uses cookies, and b) operates within a single-signon
environment. Until I'm satisfied with the completeness of the jUnit test
suite /without/ SSO, I'm not going near my own problem!
I hope you don't have a production issue, because it really will take me
all of this week to put in enough time to get round to looking at your war.
I'm a contributor, not a submitter, so there is quite a long delay
between me preparing a patch and having it committed. I develop my
changes against the trunk, which means they will apply to the next tc7
release (and also tc6 provided they are easy to implement).
Brian
p.s. you should reply to the tomcat users list, not direct to me, so
that the thread remains a complete narrative to anyone following it in
future.
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>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
