devdev2060

Gave a bit of a explanation about how JaikuEngine intends to use OAuth via an XML-RPC interface over on Jaiku so I figured I'd mostly duplicate it here.

Quick background:

JaikuEngine expects the request coming in over XML-RPC to be in the form of a single parameter which is a struct of strings (emulated in python as a dictionary of strings)

First off using XML-RPC obviously isn't covered in the spec, the spec only talks about headers and POST and GET, what we are doing however is following the spec for signing a set of request parameters.

Step 1: Get the parameters.

The spec describes three sources for parameters, the header, POST application/x-www-form-urlencoded and GET query string. The reason it specifies a content type there is to explicitly say this is data expected as key-value pairs, no mime attached files, no atompub, only things that are made of the same kind of key-values as one would expect in a query string.

In our case we choose to also allow those key-value pairs to come in via xml-rpc. When you boil it all down, what you are trying to sign is the important part of the request, in atompub the organization of the actual xml can have significance, tags will have attributes, etc; however, in xml-rpc (when used the way we are using it) the "information," the important part of the request, is just the key-value pairs, we completely ignore all that extra xml that makes up the xml-rpc protocol: all we want is the content.

Step 2: Normalize the parameters

Once you have those key-value pairs you need to apply predictable and repeatable transformations to it to make sure that each key and value looks exactly the same as it does to the person who sent them, in the case of oauth that is a specific type of urlencoding.

Regardless of where you got the variables from, be it POST, GET, headers, xml-rpc, you will have a key and a value and your web app will have successfully decoded them from whatever format they were in to the actual values of the key and the value without any escaping, that is inherently necessary if you plan on using those values to make changes to your site. From there it is a simple matter of allowing the OAuth library to normalize them for use in the signature.

When writing the OAuth libraries, I explicitly included the option of passing a parameters dict or associative array into the request constructors so that the libraries can be transport protocol agnostic.

Step 3 and onward:

I'm pretty confident you've got the rest from there, it plays out according to the spec without any hitches.