Hi folks,
I'm using J2EE form-based authentication (i.e. point the login
form at j_security_check), or at least trying to. When Tomcat reloads
classes it also flushes the session; I can see the sense in that,
since some of the objects class definitions might have changed. But
it also flushes the user's login information; is there any way to have
Tomcat preserve the login information across reloads?
Another issue I'm running into is that when the page request is a
POST, and Tomcat redirects the request to the login page, of course
the POST variables get lost. But the login process does preserve the
original URL target, and after login redirects the user back to the
original POST target, sans POST variables, which of course causes an
error.
I did some digging through the tomcat-user and tomcat-dev
archives and I saw a lot of dicussion about the whole issue of why
users should never directly request the login page, and that the user
is going to get a 4xx error if they do. Is there any way to make
tomcat handle this more gracefully? I have a check in my login paeg
that checks if tomcat.auth.originalLocation is null and sets it to the
main page. That seems to work, but is there any "standard" way to do
it?
I guess I could put a similar check in login that would compare
tomcat.auth.originalLocation against all of the JSPs and servlets that
take POST variables, and reset to the welcome page. That would kind
of kludgy, but it'd work. I'd rather check for POST in the class that
first sends the redirect (AccessInterceptor?) and either reset to the
welcome page there, or even conceivably copy the POST variables into a
Hashtable or something and have the class that sends the second
redirect (JSecurityCheck?) recreate them.
However, then I'd be running on a non-standard version
Tomcat. Short of just chucking form-based authentication and coding up
my own version, is there any way to do this more elegantly?
While I'm on the topic... Occasionally if I hit reload too fast
after copying new classes into WEB-INF/classes, I get a page with an
exception about the class reloading. Is there anywhere I can override
that, either to make it wait longer (until the class finishes
reloading) or have it send back a customized error page (ideally one
that says "Server busy reloading, please try again momentarily", plus
possibly a meta refresh to reload in 5 seconds)?
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>