You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2012/02/03 23:51:12 UTC
Form Authentication POST data not preserved?
I posted a query recently wherein I thought that POST data was being
lost *only* if the user had been authenticated, their session timed out,
and then they POST'ed to a URL requiring authentication -- thus having
their request interrupted for a form-based login.
I know Tomcat is supposed to preserve the POST data in this case as well
as in the case where one had not yet authenticated prior to the POST,
but I'd thought that the latter case worked.
As someone nicely pointed out, that makes no sense.
So here's the issue:
Neither case works. My POST data is always lost here. I've tried
various values of maxSavePostSize, including leaving it unspecified --
to no avail. [I had it set to -1 and maxPostSize also set to -1, which
I also tried leaving unspecified.]
I've tried various things -- all with no luck.
This is with Tomcat 7.0.23. I'm pretty sure I was having similar issues
with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working
in a context that's still using 7.0.23 at the moment.]
I'm left wondering what could be causing the issue.
--
Jess Holle
P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me
now. I'll be setting this to a large but still not egregious value once
I figure out the rest of this...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 11:24 AM, Jess Holle wrote:
> On 2/5/2012 11:22 AM, Jess Holle wrote:
>> On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
>>> I think this issue is specific to AJP.
>>>
>>> For HTTP connectors a similar issue was noted and fixed here:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
>>>
>>> I think adding the following line to "REQ_SET_BODY_REPLAY" case in
>>> AbstractAjpProcessor#action() will fix this bug:
>>>
>>> endOfStream = false;
>>
>> That did the trick! [I just did this via the debugger without a
>> rebuild, but same thing.]
>>
>> Could someone please patch this into trunk so it's in the next Tomcat
>> release?
> By "patch", I mean "commit", of course :-)
>> Until then I can certainly patch it into my own Tomcat. I just don't
>> want to maintain this patch forever (nor have everyone else suffer
>> from this bug in the AJP case).
Also it strikes me that maxSavePostSize should really be backed up by a
use of a SoftReference in SavedRequest.
This would allow one to allow relatively large POST bodies to be saved
unless/until this threatened to consume the JVM's overall memory
resources, at which point the POST bodies could be dropped.
As it stands now one has to choose between vicious treatment of large
POST bodies (i.e. dropping all the user's data) and opening oneself wide
open to quick and easy (and possibly accidental) DOS attacks.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 11:22 AM, Jess Holle wrote:
> On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
>> I think this issue is specific to AJP.
>>
>> For HTTP connectors a similar issue was noted and fixed here:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
>>
>> I think adding the following line to "REQ_SET_BODY_REPLAY" case in
>> AbstractAjpProcessor#action() will fix this bug:
>>
>> endOfStream = false;
>
> That did the trick! [I just did this via the debugger without a
> rebuild, but same thing.]
>
> Could someone please patch this into trunk so it's in the next Tomcat
> release?
By "patch", I mean "commit", of course :-)
> Until then I can certainly patch it into my own Tomcat. I just don't
> want to maintain this patch forever (nor have everyone else suffer
> from this bug in the AJP case).
>
> --
> Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 12:22 PM, Konstantin Kolinko wrote:
> 2012/2/5 Jess Holle <je...@ptc.com>:
>> Also it strikes me that maxSavePostSize should really be backed up by a use
>> of a SoftReference in SavedRequest.
>>
>> This would allow one to allow relatively large POST bodies to be saved
>> unless/until this threatened to consume the JVM's overall memory resources,
>> at which point the POST bodies could be dropped.
>>
>> As it stands now one has to choose between vicious treatment of large POST
>> bodies (i.e. dropping all the user's data) and opening oneself wide open to
>> quick and easy (and possibly accidental) DOS attacks.
>>
> Interesting idea. I think it is worth filing an enhancement request.
> Though I see the following caveat:
>
> Using SoftReference here will lead to non-deterministic behaviour. I
> wonder whether admins will be puzzled by this feature. Though this
> can be solved by logging an INFO message wrapped by
> org.apache.juli.logging.UserDataHelper.
Yeah, there is the element of uncertainty as to how strongly a
SoftReference really holds on to its data, etc.
This would be nice "opt in" behavior if nothing else.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/5 Jess Holle <je...@ptc.com>:
> On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
>>
>> I think this issue is specific to AJP.
>>
>> For HTTP connectors a similar issue was noted and fixed here:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
>>
>> I think adding the following line to "REQ_SET_BODY_REPLAY" case in
>> AbstractAjpProcessor#action() will fix this bug:
>>
>> endOfStream = false;
>
>
> That did the trick! [I just did this via the debugger without a rebuild,
> but same thing.]
>
> Could someone please patch this into trunk so it's in the next Tomcat
> release?
>
> Until then I can certainly patch it into my own Tomcat. I just don't want
> to maintain this patch forever (nor have everyone else suffer from this bug
> in the AJP case).
>
I filed a bug
https://issues.apache.org/bugzilla/show_bug.cgi?id=52606
It would be nice to know whether this problem is observable with 6.0.35 or not.
2012/2/5 Jess Holle <je...@ptc.com>:
>
> Also it strikes me that maxSavePostSize should really be backed up by a use
> of a SoftReference in SavedRequest.
>
> This would allow one to allow relatively large POST bodies to be saved
> unless/until this threatened to consume the JVM's overall memory resources,
> at which point the POST bodies could be dropped.
>
> As it stands now one has to choose between vicious treatment of large POST
> bodies (i.e. dropping all the user's data) and opening oneself wide open to
> quick and easy (and possibly accidental) DOS attacks.
>
Interesting idea. I think it is worth filing an enhancement request.
Though I see the following caveat:
Using SoftReference here will lead to non-deterministic behaviour. I
wonder whether admins will be puzzled by this feature. Though this
can be solved by logging an INFO message wrapped by
org.apache.juli.logging.UserDataHelper.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
> I think this issue is specific to AJP.
>
> For HTTP connectors a similar issue was noted and fixed here:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
>
> I think adding the following line to "REQ_SET_BODY_REPLAY" case in
> AbstractAjpProcessor#action() will fix this bug:
>
> endOfStream = false;
That did the trick! [I just did this via the debugger without a
rebuild, but same thing.]
Could someone please patch this into trunk so it's in the next Tomcat
release?
Until then I can certainly patch it into my own Tomcat. I just don't
want to maintain this patch forever (nor have everyone else suffer from
this bug in the AJP case).
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/5 Jess Holle <je...@ptc.com>:
> On 2/5/2012 9:43 AM, Jess Holle wrote:
>>
>> On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
>>>
>>> build.xml:
>>> <javac srcdir="java" destdir="${tomcat.classes}"
>>> debug="${compile.debug}"
>>> deprecation="${compile.deprecation}"
>>> source="${compile.source}"
>>> target="${compile.target}"
>>> optimize="${compile.optimize}"
>>> excludes="**/.svn/**"
>>> encoding="ISO-8859-1"
>>> includeAntRuntime="true">
>>>
>>> build.properties.default:
>>> compile.debug=true
>>>
>>> Thus debug information should already be there.
>>>
>>> I usually start with setting some breakpoints. In your case take a
>>> look at FormAuthenticator#saveRequest() and #restoreRequest() methods
>>> and where they are called from.
>>
>> Thanks. I've already seen via a heap dump that the request is saved with
>> the correct content body. So now the only question that remains is why it
>> does not get restored.
>
>
> Diving in deeper, I see that AbstractAjpProcessor.action() is setting the
> bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
>
> After that is done, however, I don't see anything that tries to read
> AbstractAjpProcessor.bodyBytes.
> org.apache.catalina.connector.Request.readPostBody() seems to completely
> ignore this data.
>
> I'm thinking some refactoring in this area completely broke this use case at
> least for the AJP BIO path. Or can someone offer evidence that the breakage
> is less general than this?
>
I think this issue is specific to AJP.
For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
I think adding the following line to "REQ_SET_BODY_REPLAY" case in
AbstractAjpProcessor#action() will fix this bug:
endOfStream = false;
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 10:38 AM, Jess Holle wrote:
> Diving in deeper, I see that AbstractAjpProcessor.action() is setting
> the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
>
> After that is done, however, I don't see anything that tries to read
> AbstractAjpProcessor.bodyBytes.
> org.apache.catalina.connector.Request.readPostBody() seems to
> completely ignore this data.
>
> I'm thinking some refactoring in this area completely broke this use
> case at least for the AJP BIO path. Or can someone offer evidence
> that the breakage is less general than this?
I'm not seeing any evidence as to how
org.apache.catalina.connector.Request is convinced to use the new
bodyBytes from AbstractAjpProcessor here, neither in 7.0.25 or looking
back at previous tags.
Am I missing something here?
Note that I can see how the HTTP connectors could work in this regard --
I'm just not seeing how the AJP connectors could.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 2:53 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jess,
>
> On 2/5/12 1:23 PM, Jess Holle wrote:
>> Certainly this is an optional / quality of implementation feature.
>> I'm perfectly aware that other form-based authentication solutions
>> will not save POST data and may even fail to replay requests at
>> all. That's fine and good. The application design is not
>> dependent on this behavior. Rather, Tomcat documentation says this
>> should work and it doesn't -- that's the issue.
> FWIW, SecurityFilter also provides similar capabilities. I'd be
> shocked if this wasn't industry-wide capability for servlet containers.
I was considering form-based authentication on an even broader basis --
as one can do this in the web server as instead of in the servlet engine.
That said, yes, most solutions do cover this base -- and Tomcat says it
does, but doesn't if you use an AJP connector.
Fortunately the fix is trivial to patch in.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jess,
On 2/5/12 1:23 PM, Jess Holle wrote:
> Certainly this is an optional / quality of implementation feature.
> I'm perfectly aware that other form-based authentication solutions
> will not save POST data and may even fail to replay requests at
> all. That's fine and good. The application design is not
> dependent on this behavior. Rather, Tomcat documentation says this
> should work and it doesn't -- that's the issue.
FWIW, SecurityFilter also provides similar capabilities. I'd be
shocked if this wasn't industry-wide capability for servlet containers.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8u7EkACgkQ9CaO5/Lv0PDZ0ACghcEXQ7pTElJawGg64eFQFkKS
0swAn3hcVSNeaEx9D9sXI5ZJN6ASwKhL
=Azqj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [somewhat OT] Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 12:04 PM, André Warnier wrote:
> Hi.
>
> I've just been following this thread, and this is not about the
> problem per se, but a comment about the overall design of the
> application.
>
> The fact that you do a POST without being authenticated, and that you
> rely on the server to save the POST content while the authentication
> is taking place, and to "replay" this POST after a succesful
> authentication, is not really a part of the HTTP protocol (as per RFC
> 2616).
Form-based authentication is not part of the HTTP protocol. The
entirety of form-based authentication is a complete hack of an
application convention. Some specifications, e.g. the Java servlet
specification, provide /some/ rules for form-based authentication within
their realm, but in general form-based authentication is an "anything
goes that a user running an interactive browser session can follow"
convention.
> It is a nice feature of Tomcat, and it simplifies the design of an
> application, and it avoids some user frustration.
> And maybe the paragraph cited below from the Servlet Spec is what
> "motivates" Tomcat to implement this.
>
> But I don't think tjat you can count on this behaviour with all HTTP
> servers, or all authentication schemes. For example, if instead of
> using Tomcat's container-driven authentication (declarative security),
> your application came at some point to have to use a servlet-filter
> based authentication mechanism (programmatic security), this design
> may not work anymore (unless the filter itself had some POST-saving
> scheme).
>
> Just thought I'd point that out.
Certainly this is an optional / quality of implementation feature. I'm
perfectly aware that other form-based authentication solutions will not
save POST data and may even fail to replay requests at all. That's fine
and good. The application design is not dependent on this behavior.
Rather, Tomcat documentation says this should work and it doesn't --
that's the issue.
Of course this isn't just an "application design" issue. If you're in
the midst of your application, fill out a complex form, go out to lunch,
come back and submit the form chances are good your session will have
timed out. In this case, you really want to have POST body capture
working -- otherwise usability will suffer.
> Servlet Spec 3.0, 13.6.3.1 :
> ...
> If the form based login is invoked because of an HTTP request, the
> original request
> parameters must be preserved by the container for use if, on successful
> authentication, it redirects the call to the requested resource.
> ...
>
> Note the "if".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: [somewhat OT] Form Authentication POST data not preserved?
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
I've just been following this thread, and this is not about the problem per se, but a
comment about the overall design of the application.
The fact that you do a POST without being authenticated, and that you rely on the server
to save the POST content while the authentication is taking place, and to "replay" this
POST after a succesful authentication, is not really a part of the HTTP protocol (as per
RFC 2616).
It is a nice feature of Tomcat, and it simplifies the design of an application, and it
avoids some user frustration.
And maybe the paragraph cited below from the Servlet Spec is what "motivates" Tomcat to
implement this.
But I don't think tjat you can count on this behaviour with all HTTP servers, or all
authentication schemes. For example, if instead of using Tomcat's container-driven
authentication (declarative security), your application came at some point to have to use
a servlet-filter based authentication mechanism (programmatic security), this design may
not work anymore (unless the filter itself had some POST-saving scheme).
Just thought I'd point that out.
Servlet Spec 3.0, 13.6.3.1 :
...
If the form based login is invoked because of an HTTP request, the original request
parameters must be preserved by the container for use if, on successful
authentication, it redirects the call to the requested resource.
...
Note the "if".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 9:43 AM, Jess Holle wrote:
> On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
>> build.xml:
>> <javac srcdir="java" destdir="${tomcat.classes}"
>> debug="${compile.debug}"
>> deprecation="${compile.deprecation}"
>> source="${compile.source}"
>> target="${compile.target}"
>> optimize="${compile.optimize}"
>> excludes="**/.svn/**"
>> encoding="ISO-8859-1"
>> includeAntRuntime="true">
>>
>> build.properties.default:
>> compile.debug=true
>>
>> Thus debug information should already be there.
>>
>> I usually start with setting some breakpoints. In your case take a
>> look at FormAuthenticator#saveRequest() and #restoreRequest() methods
>> and where they are called from.
> Thanks. I've already seen via a heap dump that the request is saved
> with the correct content body. So now the only question that remains
> is why it does not get restored.
Diving in deeper, I see that AbstractAjpProcessor.action() is setting
the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
After that is done, however, I don't see anything that tries to read
AbstractAjpProcessor.bodyBytes.
org.apache.catalina.connector.Request.readPostBody() seems to completely
ignore this data.
I'm thinking some refactoring in this area completely broke this use
case at least for the AJP BIO path. Or can someone offer evidence that
the breakage is less general than this?
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
> build.xml:
> <javac srcdir="java" destdir="${tomcat.classes}"
> debug="${compile.debug}"
> deprecation="${compile.deprecation}"
> source="${compile.source}"
> target="${compile.target}"
> optimize="${compile.optimize}"
> excludes="**/.svn/**"
> encoding="ISO-8859-1"
> includeAntRuntime="true">
>
> build.properties.default:
> compile.debug=true
>
> Thus debug information should already be there.
>
> I usually start with setting some breakpoints. In your case take a
> look at FormAuthenticator#saveRequest() and #restoreRequest() methods
> and where they are called from.
Thanks. I've already seen via a heap dump that the request is saved
with the correct content body. So now the only question that remains is
why it does not get restored.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/5 Jess Holle <je...@ptc.com>:
> On 2/5/2012 8:29 AM, Konstantin Kolinko wrote:
>
> 2. Enable debug logging for FormAuthenticator class.
>
> org.apache.catalina.authenticator.FormAuthenticator.level=FINE
>(...)
>
> 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 :-)
build.xml:
<javac srcdir="java" destdir="${tomcat.classes}"
debug="${compile.debug}"
deprecation="${compile.deprecation}"
source="${compile.source}"
target="${compile.target}"
optimize="${compile.optimize}"
excludes="**/.svn/**"
encoding="ISO-8859-1"
includeAntRuntime="true" >
build.properties.default:
compile.debug=true
Thus debug information should already be there.
I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator#saveRequest() and #restoreRequest() methods
and where they are called from.
Building Tomcat is documented in BUILDING.txt and in webapps/docs/building.html
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
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
Re: Form Authentication POST data not preserved?
Posted by Konstantin Kolinko <kn...@gmail.com>.
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.
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 guess I either ignore this (ouch) or really dig into debugging Tomcat's
> internals (which while far easier than trying to do so with httpd is still
> not where I'd wanted to spend my time).
>
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by 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.
I guess I either ignore this (ouch) or really dig into debugging
Tomcat's internals (which while far easier than trying to do so with
httpd is still not where I'd wanted to spend my time).
--
Jess Holle
On 2/4/2012 5:49 PM, Jess Holle wrote:
> Yes, I'm using Tomcat authentication. Yes, the issue is after
> authentication on the POST retry.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
Yes, I'm using Tomcat authentication. Yes, the issue is after
authentication on the POST retry.
On 2/4/2012 12:27 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jess,
>
> On 2/3/12 5:59 PM, Jess Holle wrote:
>> Or could this be getting loused up by having a servlet request
>> filter that calls getParameterMap() first thing?
>>
>> I'd *assume* not -- as that would be pretty hokey...
> Probably not: Tomcat's valves (including the one that performs
> authentication) all fire before any of the webapp-specified filters
> run. In any case, the problem you observe is *after* authentication
> when the POST should be re-tried, right?
>
> Silly question: you *are* using Tomcat's authentication, right? I
> mean, if you're using something else like ACEGI (does that even still
> exist -- other than as Spring Security?) then you'll have to look
> somewhere else.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk8teKEACgkQ9CaO5/Lv0PAmYwCeI0qfe5iNv/8X3z3eN4PyKtm1
> 6YYAoKteM140ZuIVbr9e01IP9aZf+rZq
> =aUyr
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jess,
On 2/3/12 5:59 PM, Jess Holle wrote:
> Or could this be getting loused up by having a servlet request
> filter that calls getParameterMap() first thing?
>
> I'd *assume* not -- as that would be pretty hokey...
Probably not: Tomcat's valves (including the one that performs
authentication) all fire before any of the webapp-specified filters
run. In any case, the problem you observe is *after* authentication
when the POST should be re-tried, right?
Silly question: you *are* using Tomcat's authentication, right? I
mean, if you're using something else like ACEGI (does that even still
exist -- other than as Spring Security?) then you'll have to look
somewhere else.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8teKEACgkQ9CaO5/Lv0PAmYwCeI0qfe5iNv/8X3z3eN4PyKtm1
6YYAoKteM140ZuIVbr9e01IP9aZf+rZq
=aUyr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
Or could this be getting loused up by having a servlet request filter
that calls getParameterMap() first thing?
I'd *assume* not -- as that would be pretty hokey...
On 2/3/2012 4:53 PM, Jess Holle wrote:
> In case this makes any difference this is with the AJP BIO connector.
>
> On 2/3/2012 4:51 PM, Jess Holle wrote:
>> I posted a query recently wherein I thought that POST data was being
>> lost *only* if the user had been authenticated, their session timed
>> out, and then they POST'ed to a URL requiring authentication -- thus
>> having their request interrupted for a form-based login.
>>
>> I know Tomcat is supposed to preserve the POST data in this case as
>> well as in the case where one had not yet authenticated prior to the
>> POST, but I'd thought that the latter case worked.
>>
>> As someone nicely pointed out, that makes no sense.
>>
>> So here's the issue:
>>
>> Neither case works. My POST data is always lost here. I've tried
>> various values of maxSavePostSize, including leaving it unspecified
>> -- to no avail. [I had it set to -1 and maxPostSize also set to -1,
>> which I also tried leaving unspecified.]
>>
>> I've tried various things -- all with no luck.
>>
>> This is with Tomcat 7.0.23. I'm pretty sure I was having similar
>> issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm
>> just working in a context that's still using 7.0.23 at the moment.]
>>
>> I'm left wondering what could be causing the issue.
>>
>> --
>> Jess Holle
>>
>> P.S. The lack of wisdom of setting maxSavePostSize is clear enough to
>> me now. I'll be setting this to a large but still not egregious
>> value once I figure out the rest of this...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
In case this makes any difference this is with the AJP BIO connector.
On 2/3/2012 4:51 PM, Jess Holle wrote:
> I posted a query recently wherein I thought that POST data was being
> lost *only* if the user had been authenticated, their session timed
> out, and then they POST'ed to a URL requiring authentication -- thus
> having their request interrupted for a form-based login.
>
> I know Tomcat is supposed to preserve the POST data in this case as
> well as in the case where one had not yet authenticated prior to the
> POST, but I'd thought that the latter case worked.
>
> As someone nicely pointed out, that makes no sense.
>
> So here's the issue:
>
> Neither case works. My POST data is always lost here. I've tried
> various values of maxSavePostSize, including leaving it unspecified --
> to no avail. [I had it set to -1 and maxPostSize also set to -1,
> which I also tried leaving unspecified.]
>
> I've tried various things -- all with no luck.
>
> This is with Tomcat 7.0.23. I'm pretty sure I was having similar
> issues with 7.0.25 as well. [No, I didn't really downgrade -- I'm
> just working in a context that's still using 7.0.23 at the moment.]
>
> I'm left wondering what could be causing the issue.
>
> --
> Jess Holle
>
> P.S. The lack of wisdom of setting maxSavePostSize is clear enough to
> me now. I'll be setting this to a large but still not egregious value
> once I figure out the rest of this...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 2/3/12 6:26 PM, Konstantin Kolinko wrote:
> 2012/2/4 Jess Holle <je...@ptc.com>:
>> I posted a query recently wherein I thought that POST data was
>> being lost *only* if the user had been authenticated, their
>> session timed out, and then they POST'ed to a URL requiring
>> authentication -- thus having their request interrupted for a
>> form-based login.
>>
>> I know Tomcat is supposed to preserve the POST data in this case
>> as well as in the case where one had not yet authenticated prior
>> to the POST, but I'd thought that the latter case worked.
>>
>> As someone nicely pointed out, that makes no sense.
>
> Why? The saved data is kept in session. If session times out (that
> means: it is removed from the server) the data that was kept in it
> becomes lost as well as the session itself.
It was I who said it made no sense, and here's why: my understanding
of Jess's situation was that he was comparing the following two cases
and saying that they behaved differently:
Case 1:
a. User logs in
b. User navigates to POST form
c. Session times out
d. User POSTs form
e. Login form is shown
f. User authenticates successfully
g. Form data is successfully re-POSTed (*)
* Jess is now saying that step (g) actually fails
Case 2:
a. User has never logged-in, yet sits on a POST form page
b. User POSTs form
c. Login form is shown
d. User authenticates successfully
e. Form data faild to be re-POSTed
Since Tomcat cannot actually differentiate between these two cases,
observing them behaving differently seems suspicious.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8tee0ACgkQ9CaO5/Lv0PDf+ACaA6It3MZPPXtMxasCDQ48/E2s
w7AAnjesutw2xiigAwSFOEST5f3uS4LA
=M+n3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Form Authentication POST data not preserved?
Posted by Jess Holle <je...@ptc.com>.
On 2/3/2012 5:26 PM, Konstantin Kolinko wrote:
> 2012/2/4 Jess Holle<je...@ptc.com>:
>> I posted a query recently wherein I thought that POST data was being lost
>> *only* if the user had been authenticated, their session timed out, and then
>> they POST'ed to a URL requiring authentication -- thus having their request
>> interrupted for a form-based login.
>>
>> I know Tomcat is supposed to preserve the POST data in this case as well as
>> in the case where one had not yet authenticated prior to the POST, but I'd
>> thought that the latter case worked.
>>
>> As someone nicely pointed out, that makes no sense.
>>
> Why? The saved data is kept in session. If session times out (that
> means: it is removed from the server) the data that was kept in it
> becomes lost as well as the session itself.
> Or maybe I do not quite understand you (try rephrase your statements,
> listing the events in chronological order).
How's this?
Case 1:
1. Browse to (anonymously accessible) data entry form without having
logged in yet
2. Click to POST data to authenticated result page URL
3. Fill in login form
4. See result page
Case 2:
1. Log in
2. Browse to data entry form (anonymous or otherwise)
3. Allow session to time out (or force this on the server)
4. Click to POST data to authenticated result page URL
5. Fill in login form
6. See result page
I'd expect to see the results in both cases reflect the POST data.
Initially I had thought that Case #1 worked but Case #2 didn't. That
makes no sense -- as others pointed out.
Now I see that neither case works.
--
Jess Holle
Re: Form Authentication POST data not preserved?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/2/4 Jess Holle <je...@ptc.com>:
> I posted a query recently wherein I thought that POST data was being lost
> *only* if the user had been authenticated, their session timed out, and then
> they POST'ed to a URL requiring authentication -- thus having their request
> interrupted for a form-based login.
>
> I know Tomcat is supposed to preserve the POST data in this case as well as
> in the case where one had not yet authenticated prior to the POST, but I'd
> thought that the latter case worked.
>
> As someone nicely pointed out, that makes no sense.
>
Why? The saved data is kept in session. If session times out (that
means: it is removed from the server) the data that was kept in it
becomes lost as well as the session itself.
Or maybe I do not quite understand you (try rephrase your statements,
listing the events in chronological order).
The session is created once the session-id cookie is sent to the user.
That happens before authentication.
>(...)
>
> P.S. The lack of wisdom of setting maxSavePostSize is clear enough to me
> now. I'll be setting this to a large but still not egregious value once I
> figure out the rest of this...
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org