Issue when using clj-oauth with Shapeways API

[theJenix]

Hi.

I'm trying to use clj-oauth to integrate the Shapeways API (https://developers.shapeways.com/, uses Oauth 1.0) into my Clojure app, and am running into an issue with the request-token response. It looks like they return the oauth_token value in the authentication_url (not as a separate key/value pair), and it looks like they screwed up the URL encoding such that there is an unescaped = sign in the authentication_url value. E.g.
authentication_url=http%3A%2F%2Fapi.shapeways.com%2Flogin%3Foauth_token=SECRET&oauth_token_secret=SECRET2&oauth_callback_confirmed=true

When this is decoded, and the map returned to me, I get:
{:authentication_url http://api.shapeways.com/login?oauth_token, :oauth_token_secret SECRET2, :oauth_callback_confirmed true}

The reason this is happening is because of how the string is parsed in oauth.client/form-decode. It splits each parameter on "=" and then takes the first 2 values in that sequence, which throws away SECRET after "oauth_token=..." in this case. A solution to this problem could be to limit that split to only 2 splits, which will always split on the first = found (I've tested this in my local copy and it works for my situation). Another solution to this problem could be to let me bind my own form-decode function (thus letting me hack around an error in the API in my own code). I'm happy to implement and issue a pull request, but I'd love some guidance on which solution you'd prefer for the library.

As a secondary question, I'm pretty new to Oauth but this pattern (of using an authentication url from the request-token, instead of defined in the Consumer) doesn't seem well supported by clj-oauth. Am I understanding that correctly, and is there "right" way to support this pattern?

Thanks!

[drone29a]

I'm not sure how common sending the entire authentication URL is, but AFAIK it's not part of the OAuth v1 spec. Some references:

• http://oauth.net/core/1.0/#auth_step1
• http://oauth.net/core/1.0/#response_parameters
• https://dev.twitter.com/oauth/reference/post/oauth/request_token

I'd suggest filing a bug report with them first, it's not a great idea to hack support into clj-oauth to support specific API quirks/errors. Are you comfortable with using your local hack as a workaround until they respond? If they're adamant about it not being a bug or simply refusing to fix their API, let me know and we'll figure out the least gross hack to make clj-oauth work with Shapeways.

[theJenix]

I'm comfortable with the hack for now, and definitely agree that it's not worth hacking support into the library for specific API quirks. I'll post a response here when they respond. Thanks!

[theJenix]

I finally heard back from Shapeways, and they acknowledged the issue but I get the impression that it's fairly low priority for them. I don't think we need to change clj-oauth to support Shapeway's quirk, but I do think the core library should have some functionality to let developers hack around bad APIs without having to modify core clj-oauth code. What if you let developers pass a custom decode function as an argument to make-consumer or request-token? My local hack has a similar effect: by limiting splits on "=" to 2, the 2nd element in each split could be parsed by the consumer code. This is not as clean as just supplying a custom decode function on the outset, though.

[drone29a]

Closing in favor of #59