On 2/5/2012 8:29 AM, Konstantin Kolinko wrote:
2012/2/5 Jess Holle<je...@ptc.com>:
I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25
and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a
combination of 2 JNDI realms to 1, cranking lots of loggers up to full
verbosity, etc.
In all cases I lose the POST parameters.
1. You have to pay attention to Cookie/Set-Cookie headers that are
sent between Server and Client. The value there is session id.
Just a note: upon successful authentication there should be one more
Set-Cookie header sent by the server, because session id will be
changed (but not the session itself).
You can use browser plugins (like Firefox Live Http Headers or
Firebug), network sniffers (Wireshark) or just configure your access
log to log those headers.
The standard Tomcat Manager web application can be used to inspect
active sessions and their attributes.
Nothing appears to be amiss with respect to Set-Cookie and Cookie headers.
2. Enable debug logging for FormAuthenticator class.
org.apache.catalina.authenticator.FormAuthenticator.level=FINE
If you configure logging to use OneLineFormatter, it will include
thread id and it will be easier to match it against access log (if
access log is configured to print thread ids as well). E.g.
1catalina.org.apache.juli.FileHandler.formatter =
org.apache.juli.OneLineFormatter
I had already increased verbosity for FormAuthenticator -- nothing
seemed amiss from what I could tell there. It /said/ it was restoring
the original request from the session. I never see anything about a
POST body being restored, but I'm not sure if there is any logging to
this effect.
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Thanks. I've got that part down. The harder part is rebuilding pieces
of Tomcat with full debug information (I'm assuming Tomcat is normally
not built with local variable debug information) and finding my way
through unfamiliar code. But that's life :-)
--
Jess Holle
