Things are not quite settled yet to how this will be dealt with,
The OAuth spec does indeed state it should include the POST Parameters with
form-urlencoded POSTs, however this is intended for having actual params
(foo=a&bar=b), and not for posting a JSON/XML/Atom documents as we're doing.
So even though php-shindig supports that, it's somewhat invalid since it's
the wrong use of form-encoded post's, and also java shindig can't mimic this
behavior since the servlet engines don't make the raw post body available on
form-urlencoded posts.
The OAuth spec doesn't say anything about other content-type posts (like the
application/{json, xml, xml+atpm} we use), so according to the current OAuth
spec they shouldn't be signed, which means that those requests would be
vunerable to man-in-the-middle attacks (ie: the post content could be
modified in transit), which isn't an acceptable situation for us, we want to
have this protection.
So to solve this situation, Brian is working on a new OAuth spec proposal
which covers this signing the post body of other content types:
http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/3/spec.html
Once the dust settles for this, I'll modify php-shindig to:
- Not include the json/xml/atom document of the post body in the oauth
signature calculation for www-url-formencoded POSTs
- Do include the json/xml/atom document of the post body for
application/{json, xml, xml+atom, (and variants)} POSTs
Which should make it consistent with both the OAuth spec's, and how Java
shindig will work.
As I pointed out in my earlier post though, there are live sites which have
the old behavior, so we should keep that in mind for the REST/RPC client
libs and add an option to them to allow the old style including the
form-urlencoded post body in the signature for those 'legacy' sites.
Hope that clears things up a bit :)
-- Chris
On Sun, Mar 15, 2009 at 5:48 AM, Chirag Shah <[email protected]> wrote:
> > Currently PHP Shindig always includes the POST body in the OAuth
> signature
> > checking, even if it's www-form-urlencoded, it'll use the raw post body.
>
> Does this mean PHP Shindig is signing the POST body when the content
> type is application/{json,xml,atom+xml)?
>
> If so, I thought the POST body should only be included in the OAuth
> signature when the content-type is x-www-form-urlencoded.
> (At least that's how I interpreted section 9.1 of the OAuth spec
> http://oauth.net/core/1.0/#anchor14 )
>
> On Sat, Mar 14, 2009 at 10:22 AM, Chris Chabot <[email protected]> wrote:
> > Currently PHP Shindig always includes the POST body in the OAuth
> signature
> > checking, even if it's www-form-urlencoded, it'll use the raw post body.
> >
> > Also it only supports the application/{json,xml,atom+xml) content-type
> > headers and won't recognize things like text/xml or
> application/javascript.
> >
> > I'd be more then happy to adjust any of these things (not including the
> post
> > body on form-urlencoded, and adding support for the extra content type
> > headers, and even if you have a strong preference making the default
> output
> > content-type application/javascript), as far as code goes those changes
> are
> > pretty small.
> >
> > However we do have a 20-something medium to very large SNS's using
> > PHP-Shindig, and in my experience it can take months before everyone is
> > adjusted to a code update or a new spec, so it might be worth seeing what
> we
> > can live with, and minimizes the amount of breakage it'll cause in the
> > transition phase.
> >
> > On Sat, Mar 14, 2009 at 12:59 AM, Louis Ryan <[email protected]> wrote:
> >
> >> Chris
> >>
> >> I've implemented strict content type check for REST/RPC endpoint in Java
> >> shindig (see http://codereview.appspot.com/28042/show). The next thing
> Id
> >> like to figure out the variance between Java and PHP Shindig for body
> >> signing, in particular what happens currently in PHP to the signature
> base
> >> string when the content type is application/x-www-form-urlencoded but
> the
> >> body is JSON. For backwards compatability the Java implementation will
> need
> >> to do the same thing when the new content signing mechanism is not being
> >> used.
> >>
> >> -Louis
> >>
> >
>
