OAuth body signing does not work in Shindig and the specification is unclear
----------------------------------------------------------------------------
Key: SHINDIG-974
URL: https://issues.apache.org/jira/browse/SHINDIG-974
Project: Shindig
Issue Type: Bug
Components: Java
Affects Versions: trunk
Reporter: Louis Ryan
Assignee: Louis Ryan
Priority: Blocker
Fix For: trunk
Shindig can not and will not handle OAuth body signing of a request where the
Content-Type header is "application/x-www-form-urlencoded" but the acutal body
content is a different type such as "application/json". PHP Shindig currently
allows this because it has access to the raw content body when the content type
is set to form-encoded and so can include the raw body content in the OAuth
signature base string. The Servlet spec does not allow us to access the body
when form-encoded is the content type and there is no way to reasonably
reconstruct it (see below). There is a new OAuth body signing proposal
(http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.html)
being reviewed on the OpenSocial spec list currently to more thoroughly address
this issue. In the meantime Java shindig should:
1. Disallow POST/PUT requests of Content-Type form-urlencoded to the social API
endpoints with a clear error message.
2. In the case where the new body signing oauth_body_hash parameter IS NOT
available then include the raw body in the OAuth base string for signature
verification the same was PHP Shindig does. This should allow API clients which
are working with PHP Shindig to work with Java Shinding just by switching the
content-type header.
3. In the case where the new body signing oauth_body_hash parameter IS
AVAILABLE then use the new OAuth body signing verification mechanism
After a period of time when containers and clients are updated to handle the
new OAuth signing mechansim we should remove support for 2.
>From the Servlet 2.5 spec:
SRV.3.1.1:
The following are the conditions that must be met before post form data will
be populated to the parameter set:
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of
methods on the request object. If the conditions are not met and the post form
data is not included in the parameter set, the post data must still be
available to the servlet via the request object's input stream. If the
conditions are met, post form data will no longer be available for reading
directly from the request object's input stream
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
