You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Louis Ryan (JIRA)" <ji...@apache.org> on 2009/03/14 00:56:50 UTC

[jira] Commented: (SHINDIG-974) OAuth body signing does not work in Shindig and the specification is unclear

    [ https://issues.apache.org/jira/browse/SHINDIG-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681943#action_12681943 ] 

Louis Ryan commented on SHINDIG-974:
------------------------------------

First step of strict content type checks for review

http://codereview.appspot.com/28042/show

> 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.