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
