...
The tokens are in the event attribute content and are URL encoded. You can see how decode_content() works in another recipe. The callback is the event we want Dropbox to raise when it responds with the access token. The event is an oauth:response event. We take pains using meta:host() and meta:rid() to ensure that this code is portable between KRE instances and rulesets. The form of the URL that calls Dropbox is described in their documentation. The rule postlude stores the request token and request token secret. Note that Dropbox returns them labeled as oauth_token and oauth_token_secret.
When this rule runs, the user will see something like this:
Screen Shot 2013-05-30 at 11.31.07 AM.png
After the click, they'll see this dialog at Dropbox:
Screen Shot 2013-05-30 at 11.32.52 AM.png
Getting the Access Token
Because we set the callback URL as an ESL that raises a oauth:response event to the current ruleset, we need a rule that is selected on that event. The rule can use the access token endpoint to retrieve the token and its associated secret.
...
The result from the HTTP GET always contains the entire HTTP result. The content of the response is stored as a JSON string in the content field of the result object, so we select that from any response and decode() it to get a KRL data structure.
The result looks like this:
Screen Shot 2013-05-30 at 11.33.45 AM.png
Conclusion
This recipe has shown how to use the Dropbox API and OAuth 1.0a from within KRL. The OAuth interactions have been handled completely within KRL. This recipe could be easily adapted to any OAuth 1.0a protected resource as long as it supports PLAINTEXT signatures. OAuth 2 is considerably simpler and should be easily doable using the techniques outlined above.
...