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
>
