You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Nicholas Sushkin <ns...@openfinance.com> on 2011/09/29 21:37:43 UTC
Should Form Authentication Valve restore request body on a PUT?
In Tomcat 6, Form Authentication valve restores the original request after a
POST with successful authentication and redirect is followed by the client's
GET. In case of the POST, the valve also restores the original request's body.
However, it doesn't do that for a PUT. If I am not mistaken, it should restore
the body on PUT as well. Do I misunderstand something?
The patch would be in FormAuthenticator.restoreRequest(Request, Session) [1],
to change from
if ("POST".equalsIgnoreCase(saved.getMethod())) {
to
if ("POST".equalsIgnoreCase(saved.getMethod()) ||
"PUT".equalsIgnoreCase(saved.getMethod())
) {
[1]
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/authenticator/FormAuthenticator.java?view=markup#l450
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940
I left all the flags at their default settings.
Thanks!
On Saturday, October 01, 2011 07:20:21 Mark Thomas wrote:
> On 30/09/2011 17:09, Nicholas Sushkin wrote:
> > Mark, Chris, thanks for the review.
> >
> >
> > Should filing a bug be my next step, then?
>
> Please.
>
> Mark
>
> > On Friday, September 30, 2011 13:10:55 Mark Thomas wrote:
> >> > Basically my thinking is that you handle POST, shouldn't you also
> >> >
> >> > implement PUT the same way, to be consistent?
> >>
> >> I'd have no objection so the proposed change.
> >>
> >>
> >>
> >> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Mark Thomas <ma...@apache.org>.
On 30/09/2011 17:09, Nicholas Sushkin wrote:
> Mark, Chris, thanks for the review.
>
>
> Should filing a bug be my next step, then?
Please.
Mark
>
>
> On Friday, September 30, 2011 13:10:55 Mark Thomas wrote:
>
>> > Basically my thinking is that you handle POST, shouldn't you also
>
>> > implement PUT the same way, to be consistent?
>
>>
>
>> I'd have no objection so the proposed change.
>
>>
>
>> Mark
> --
>
> Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
>
> Open Finance - Secure, Accurate, Industrial Strength Aggregation
>
> <http://www.openfinance.com>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
Mark, Chris, thanks for the review.
Should filing a bug be my next step, then?
On Friday, September 30, 2011 13:10:55 Mark Thomas wrote:
> > Basically my thinking is that you handle POST, shouldn't you also
> > implement PUT the same way, to be consistent?
>
> I'd have no objection so the proposed change.
>
> Mark
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Mark Thomas <ma...@apache.org>.
On 30/09/2011 12:20, Nicholas Sushkin wrote:
> I can go into more details, if you wish, but basically I am using
> Forgerock OpenAM, which is a single signon/access manager product which
> has its own valve that hooks into the application's login URLs defined
> in form authentication, returns a login form with prepopulated username
> and password fields, with html body having javascript onbody submit. I
> think it's their way to have Tomcat evaluate J2EE roles and soon. When
> using browser, this all happens transparent to the user and the form is
> being automatically submitted by the browser's javascript. When REST API
> is being used (that's where a PUT is required), Tomcat throws
> authentication form once its session expires, and this may happen on any
> method. GET and POST are handled correctly, but not PUT. PUT's body is
> always lost because the the Form Authentication doesn't restore it.
>
>
> Basically my thinking is that you handle POST, shouldn't you also
> implement PUT the same way, to be consistent?
I'd have no objection so the proposed change.
Mark
>
>
> On Thursday, September 29, 2011 17:04:27 Christopher Schultz wrote:
>
>> I do have one question: why are you using Form-based authentication
>
>> with PUT requests? It seems like HTTP Digest or something like that
>
>> would make more sense when clients can expect to send data without
>
>> being challenged a-priori for credentials.
>
>>
>
>> Another workaround would just be to use POST.
> --
>
> Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
>
> Open Finance - Secure, Accurate, Industrial Strength Aggregation
>
> <http://www.openfinance.com>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
I can go into more details, if you wish, but basically I am using Forgerock
OpenAM, which is a single signon/access manager product which has its own
valve that hooks into the application's login URLs defined in form
authentication, returns a login form with prepopulated username and password
fields, with html body having javascript onbody submit. I think it's their way
to have Tomcat evaluate J2EE roles and soon. When using browser, this all
happens transparent to the user and the form is being automatically submitted
by the browser's javascript. When REST API is being used (that's where a PUT
is required), Tomcat throws authentication form once its session expires, and
this may happen on any method. GET and POST are handled correctly, but not
PUT. PUT's body is always lost because the the Form Authentication doesn't
restore it.
Basically my thinking is that you handle POST, shouldn't you also implement
PUT the same way, to be consistent?
On Thursday, September 29, 2011 17:04:27 Christopher Schultz wrote:
> I do have one question: why are you using Form-based authentication
> with PUT requests? It seems like HTTP Digest or something like that
> would make more sense when clients can expect to send data without
> being challenged a-priori for credentials.
>
> Another workaround would just be to use POST.
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
Yup. The body of the POST got written into my login.html. Took me a while to
notice that. Good one!
On Friday, October 07, 2011 10:13:00 Christopher Schultz wrote:
> If that's what's happening, the DefaultServlet is handling the
> request, seeing that it is a PUT, and then complaining that it's
> read-only. When you make the DefaultServlet read-write you tell the
> DefaultServlet to accept uploads, and you'll probably end up
> overwriting your login form with the request entity (oops).
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 1:59 PM, Nicholas Sushkin wrote:
>
> The bug was that if you do an unauthenticated POST, PUT, or DELETE,
> the Form Authentication valve was trying to do a POST, PUT, or DELETE
> to the login form. The correct behaviour IMHO is to always GET the
> login form and return it as a response to the unauthenticated request
> of any kind. Then, once the form is POSTed and authentication is
> successful, the original request whatever it may have been, should be
> replayed. Right?
>
>
> On Friday, October 07, 2011 16:07:20 Nicholas Sushkin wrote:
>
> > Before being forwarded to login page, the request is saved and only then
>
> > turned into GET, before dispatching the forward to the login page. After
>
> > login form is submitted, the original request is restored from the saved
>
> > state and is replayed.
>
> --
>
> Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
>
> Open Finance - Secure, Accurate, Industrial Strength Aggregation
>
> <http://www.openfinance.com>
>
Sounds logical but modifying data on the server:
1) after being diverted to the login form
2) without any type of confirmation
makes me a little uncomfortable.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Should Form Authentication Valve restore request body on a PUT?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nicholas Sushkin [mailto:nsushkin@openfinance.com]
> Subject: Re: Should Form Authentication Valve restore request body on a PUT?
> The correct behaviour IMHO is to always GET the login form and return
> it as a response to the unauthenticated request of any kind. Then, once
> the form is POSTed and authentication is successful, the original request
> whatever it may have been, should be replayed. Right?
Yes, that sounds correct. It wasn't clear to me in what order things were being done.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
The bug was that if you do an unauthenticated POST, PUT, or DELETE, the Form
Authentication valve was trying to do a POST, PUT, or DELETE to the login
form. The correct behaviour IMHO is to always GET the login form and return it
as a response to the unauthenticated request of any kind. Then, once the form
is POSTed and authentication is successful, the original request whatever it
may have been, should be replayed. Right?
On Friday, October 07, 2011 16:07:20 Nicholas Sushkin wrote:
> Before being forwarded to login page, the request is saved and only then
> turned into GET, before dispatching the forward to the login page. After
> login form is submitted, the original request is restored from the saved
> state and is replayed.
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
Before being forwarded to login page, the request is saved and only then
turned into GET, before dispatching the forward to the login page. After login
form is submitted, the original request is restored from the saved state and
is replayed.
On Friday, October 07, 2011 12:51:48 Caldarale, Charles R wrote:
> I'm confused. If you turn a PUT into a GET, it would seem that the request
> will likely be badly mishandled once the login process is complete and the
> original request is sent on to the target servlet/JSP. Am I missing
> something?
>
> - Chuck
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
RE: Should Form Authentication Valve restore request body on a PUT?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Nicholas Sushkin [mailto:nsushkin@openfinance.com]
> Subject: Re: Should Form Authentication Valve restore request body on a PUT?
> I set request method to "GET" on all unauthenticated requests that
> forward to the login page.
I'm confused. If you turn a PUT into a GET, it would seem that the request will likely be badly mishandled once the login process is complete and the original request is sent on to the target servlet/JSP. Am I missing something?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
Charles,
Thanks for the suggestion.
I set request method to "GET" on all unauthenticated requests that forward to
the login page. That tested well for all RESTful methods, POST, PUT, GET, and
DELETE.
Submitted a patch.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c2
On Friday, October 07, 2011 10:13:00 Christopher Schultz wrote:
> Since you're just hacking, try setting the request method to "GET"
> when you detect a PUT request that requires authentication.
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicholas,
On 10/6/2011 10:08 PM, Nicholas Sushkin wrote:
> I now reconfigured DefaultServlet in conf/web.xml with
> readonly=false. Now, an unauthenticated PUT (with or without a
> body) returns 204 No Content instead of the login form. Seems like
> a bug. Should I add this behavior to Bug #51940 or a new bug?
I'll bet what is happening is that your PUT request is being forwarded
without modification to the login page, and your login page is some
static content. Is that right?
If that's what's happening, the DefaultServlet is handling the
request, seeing that it is a PUT, and then complaining that it's
read-only. When you make the DefaultServlet read-write you tell the
DefaultServlet to accept uploads, and you'll probably end up
overwriting your login form with the request entity (oops).
It looks like the authenticator code needs to transform the PUT
request into a GET (or POST?) so that the DefaultServlet doesn't try
to do an upload.
I think you'd have similar problems if trying to use a JSP for your
login-page, because JSPs can't accept PUT requests unless specifically
configured to do so.
Since you're just hacking, try setting the request method to "GET"
when you detect a PUT request that requires authentication.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6PCOwACgkQ9CaO5/Lv0PB5lwCeNN0fxcnPVAZG7UaY6ywQsR/A
xNQAn1TbTs0QqPT4FspU9yPFoNNL5PjO
=mkME
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
I now reconfigured DefaultServlet in conf/web.xml with readonly=false. Now, an
unauthenticated PUT (with or without a body) returns 204 No Content instead of
the login form. Seems like a bug. Should I add this behavior to Bug #51940 or
a new bug?
On Thursday, October 06, 2011 16:35:16 Nicholas Sushkin wrote:
> Ok, traced the 403 to DefaultServlet being readonly, which is somehow
> relevant during login form forward.
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
Ok, traced the 403 to DefaultServlet being readonly, which is somehow relevant
during login form forward.
On Thursday, October 06, 2011 18:27:13 Nicholas Sushkin wrote:
> I found out that in Tomcat 6.0 trunk, if user is not authentication and app
> is configured for FORM authentication, POST and GET requests return 200 and
> the login form, but PUT returns 403 and error page. What might explain the
> difference in handling PUT?
>
> I tried to run in debugger, but it wasn't immediately obvious.
> forwardToLoginPage is called in all cases, but there is some difference in
> the way dispatcher processes the forward.
--
Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations
Open Finance - Secure, Accurate, Industrial Strength Aggregation
<http://www.openfinance.com>
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Nicholas Sushkin <ns...@openfinance.com>.
I found out that in Tomcat 6.0 trunk, if user is not authentication and app is
configured for FORM authentication, POST and GET requests return 200 and the
login form, but PUT returns 403 and error page. What might explain the
difference in handling PUT?
I tried to run in debugger, but it wasn't immediately obvious.
forwardToLoginPage is called in all cases, but there is some difference in the
way dispatcher processes the forward.
Thanks.
On Thursday, September 29, 2011 17:04:27 Christopher Schultz wrote:
> Nicholas,
>
> On 9/29/2011 3:37 PM, Nicholas Sushkin wrote:
> > In Tomcat 6, Form Authentication valve restores the original
> > request after a POST with successful authentication and redirect is
> > followed by the client's GET. In case of the POST, the valve also
> > restores the original request's body. However, it doesn't do that
> > for a PUT.
>
> That's not entirely surprising.
>
> > If I am not mistaken, it should restore the body on PUT as well. Do
> > I misunderstand something?
>
> The servlet spec (v3.0, SRV 13.6.3.1) has this to say:
> "
> 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.
> "
>
> It doesn't say what kinds of HTTP verbs should or should not be
> supported, but GET and PUT seem entirely obvious. It doesn't say that
> the request body needs to be maintained, only the "request
> parameters". Since the servlet specification doesn't have any
> provisions for fetching request parameters from PUT operations, I
> suppose the spec therefore doesn't directly recommend that PUT bodies
> be stored for later use like when POST is used.
>
> > The patch would be in FormAuthenticator.restoreRequest(Request,
> > Session) [1], to change from
> >
> > if ("POST".equalsIgnoreCase(saved.getMethod())) {
> >
> > to
> >
> > if ("POST".equalsIgnoreCase(saved.getMethod()) ||
> > "PUT".equalsIgnoreCase(saved.getMethod())) {
>
> On the face of it, that seems reasonable. I haven't read-through the
> code that then replays the saved-request so I'm not sure if there's
> more to be done.
>
> I do have one question: why are you using Form-based authentication
> with PUT requests? It seems like HTTP Digest or something like that
> would make more sense when clients can expect to send data without
> being challenged a-priori for credentials.
>
> Another workaround would just be to use POST.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
--
Nicholas Sushkin
Senior Software Engineer, Manager of IT Operations
OpenFinance
62 Chelsea Piers, Suite 316
New York, NY 10011
+1 646 723 2790 (o)
nsushkin@openfinance.com
CONFIDENTIALITY NOTICE: This e-mail message and any attachments are only for
the use of the intended recipient and may contain information that is
privileged, confidential or exempt from disclosure under applicable law. If
you are not the intended recipient, any disclosure, distribution or other use
of this e-mail message or attachments is prohibited. If you have received this
e-mail message in error, please delete and notify the sender immediately.
Thank you.
Re: Should Form Authentication Valve restore request body on a PUT?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicholas,
On 9/29/2011 3:37 PM, Nicholas Sushkin wrote:
> In Tomcat 6, Form Authentication valve restores the original
> request after a POST with successful authentication and redirect is
> followed by the client's GET. In case of the POST, the valve also
> restores the original request's body. However, it doesn't do that
> for a PUT.
That's not entirely surprising.
> If I am not mistaken, it should restore the body on PUT as well. Do
> I misunderstand something?
The servlet spec (v3.0, SRV 13.6.3.1) has this to say:
"
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.
"
It doesn't say what kinds of HTTP verbs should or should not be
supported, but GET and PUT seem entirely obvious. It doesn't say that
the request body needs to be maintained, only the "request
parameters". Since the servlet specification doesn't have any
provisions for fetching request parameters from PUT operations, I
suppose the spec therefore doesn't directly recommend that PUT bodies
be stored for later use like when POST is used.
> The patch would be in FormAuthenticator.restoreRequest(Request,
> Session) [1], to change from
>
> if ("POST".equalsIgnoreCase(saved.getMethod())) {
>
> to
>
> if ("POST".equalsIgnoreCase(saved.getMethod()) ||
> "PUT".equalsIgnoreCase(saved.getMethod())) {
On the face of it, that seems reasonable. I haven't read-through the
code that then replays the saved-request so I'm not sure if there's
more to be done.
I do have one question: why are you using Form-based authentication
with PUT requests? It seems like HTTP Digest or something like that
would make more sense when clients can expect to send data without
being challenged a-priori for credentials.
Another workaround would just be to use POST.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6E3VsACgkQ9CaO5/Lv0PD67gCdGvoSAw3CJKRokEg0GNvDz7Tn
62oAnjovksaQNSkPiPDXg9jl9RSROVup
=JpnY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org