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
-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
> al
On 2/5/2012 12:22 PM, Konstantin Kolinko wrote:
2012/2/5 Jess Holle :
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 th
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
2012/2/5 Jess Holle :
> 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
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 th
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 p
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
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
AbstractAjpProcesso
2012/2/5 Jess Holle :
> On 2/5/2012 9:43 AM, Jess Holle wrote:
>>
>> On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
>>>
>>> build.xml:
>>> >> debug="${compile.debug}"
>>> deprecation="${compile.deprecation}"
>>> source="${compile.source}"
>>> target="${co
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.apa
On 2/5/2012 9:43 AM, Jess Holle wrote:
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
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#saveReque
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
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
2012/2/5 Jess Holle :
> 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
On 2/5/2012 8:29 AM, Konstantin Kolinko wrote:
2012/2/5 Jess Holle:
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
ver
2012/2/5 Jess Holle :
> 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
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 e
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 re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Konstantin,
On 2/3/12 6:26 PM, Konstantin Kolinko wrote:
> 2012/2/4 Jess Holle :
>> 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'
-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 (in
On 2/3/2012 5:26 PM, Konstantin Kolinko wrote:
2012/2/4 Jess Holle:
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
i
2012/2/4 Jess Holle :
> 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
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
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 aut
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 pr
25 matches
Mail list logo
