Re: Should Form Authentication Valve restore request body on a PUT?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
RE: Should Form Authentication Valve restore request body on a PUT?
From: Nicholas Sushkin [mailto:nsush...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
RE: Should Form Authentication Valve restore request body on a PUT?
From: Nicholas Sushkin [mailto:nsush...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@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)
nsush...@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.
smime.p7s
Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Nicholas Sushkin, Senior Software Engineer, Manager of IT Operations Open Finance - Secure, Accurate, Industrial Strength Aggregation http://www.openfinance.com smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Should Form Authentication Valve restore request body on a PUT?
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 smime.p7s Description: S/MIME cryptographic signature
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
smime.p7s
Description: S/MIME cryptographic signature
Re: Should Form Authentication Valve restore request body on a PUT?
-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
