[
https://issues.apache.org/jira/browse/SHINDIG-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Louis Ryan closed SHINDIG-974.
------------------------------
Resolution: Fixed
> 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: 1.1-M1
> Reporter: Louis Ryan
> Assignee: Louis Ryan
> Priority: Blocker
> Fix For: 1.1-M1
>
>
> 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.
