Implementing OAuth questions

bziclix

I'll be the first to admit I don't totally get OAuth *yet* so take it easy on me if you will.

First, I develop primarily libraries for accessing the API and would like, if it makes sense, to provide OAuth functionality in addition to the login.* methods already available. Does it make sense? Should the OAuth dance be down outside of the library and I provide a means to just pass the tokens through?

Secondly, is the API key the same as the "key" referred to in the OAuth docs? Is the "secret" listed on on the Control Panel -> Settings the OAuth secret?

I'm sure I'll have more questions, but I'm not past this part yet.

thanks, brian

--

Brian Zimmer / bzimmer.ziclix.com

lildude

bziclix wrote:

I'll be the first to admit I don't totally get OAuth *yet* so take it easy on me if you will.

First, I develop primarily libraries for accessing the API and would like, if it makes sense, to provide OAuth functionality in addition to the login.* methods already available. Does it make sense? Should the OAuth dance be down outside of the library and I provide a means to just pass the tokens through?

I'd say it makes sense to do as much of the OAuth stuff within the lib as you can, but I think due to the required user interaction, you may be quite limited to what you can do soles in the lib.

Secondly, is the API key the same as the "key" referred to in the OAuth docs? Is the "secret" listed on on the Control Panel -> Settings the OAuth secret?

Sort of.

oauth_consumer_key = API key

SmugMug isn't implementing any form of oauth_consumer_secret that I can see, and from my initial testing, leaving it blank works a treat.

devbobo

If you go to your control panel, click the 'change' link next to your api key and then click the Save button....an api secret will be generated for you.

lildude

devbobo wrote:

If you go to your control panel, click the 'change' link next to your api key and then click the Save button....an api secret will be generated for you.

Aaah, it all starts to fall into place now. Is the secret absolutely necessary? (Just thinking about people who move to the 1.2.2 API without doing this).

devbobo

lildude wrote:

Aaah, it all starts to fall into place now. Is the secret absolutely necessary? (Just thinking about people who move to the 1.2.2 API without doing this).

for OAuth, yes it's required.

If you just want to use the old login methods, it's not required.

jfew

oauth_signature?
I'm trying to get a request token but keep encountering invalid signature errors. What value should be passed in via oauth_signature? I'm using oauth_signature_method of PLAINTEXT. The OAuth spec shows a string concatenating the consumer secret (aka the SmugMug API secret?) and the token secret (which as far as I can tell doesn't apply to the request token call).

devbobo

jfew wrote:

I'm trying to get a request token but keep encountering invalid signature errors. What value should be passed in via oauth_signature? I'm using oauth_signature_method of PLAINTEXT. The OAuth spec shows a string concatenating the consumer secret (aka the SmugMug API secret?) and the token secret (which as far as I can tell doesn't apply to the request token call).

what's your SmugMug nickname, so I can check something on your account ?

jfew

devbobo wrote:

what's your SmugMug nickname, so I can check something on your account ?

Nickname is jfew.

devbobo

jfew wrote:

I'm trying to get a request token but keep encountering invalid signature errors. What value should be passed in via oauth_signature? I'm using oauth_signature_method of PLAINTEXT. The OAuth spec shows a string concatenating the consumer secret (aka the SmugMug API secret?) and the token secret (which as far as I can tell doesn't apply to the request token call).

so, the spec says that the PLAINTEXT signature should be "B]oauth_consumer_key[/B%26B]oauth_token_secret[/B".

But when you don't have an oauth_token, the PLAINTEXT signature is 'B]oauth_consumer_key[/B%26'

OAuth Spec wrote:

9.4.1. Generating Signature

oauth_signature is set to the concatenated encoded values of the Consumer Secret and Token Secret, separated by a ‘&’ character (ASCII code 38), even if either secret is empty. The result MUST be encoded again.
These examples show the value of oauth_signature for Consumer Secret djr9rjt0jd78jf88 and 3 different Token Secrets:

jjd999tj88uiths3:
oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3

jjd99$tj88uiths3:
oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3

Empty:
oauth_signature=djr9rjt0jd78jf88%26

gyrus

ok I feel kind of stupid seemingly asking this again, but since I'm having trouble..

(I'm using the oauth client python code from http://code.google.com/p/oauth/ )
the server I'm connecting to is api.smugmug.com, port 80
I'm requesting a token using url: 'http://api.smugmug.com/services/oauth/getRequestToken.mg'

I set the consumer_key to the Api key in control panel.
I set the consumer_secret to the secret listed to the right of the api key.

given this input, the library is generating the parameters as:
{
'oauth_nonce': '38040734',
'oauth_timestamp': 1215562755,
'oauth_consumer_key': 'consumer_key',
'oauth_signature_method': 'PLAINTEXT', 'oauth_version': '1.0',
'oauth_signature': 'consumer_secret&'
}

the response I'm getting is "invalid signature".

for the parameter "oauth_signature", I've tried a whole slew of combinations, such as:
'consumer_secret%26'
'consumer_key%26'
'consumer_key&'
'consumer_key&consumer_secret'
'consumer_secret&consumer_key'
'consumer_key%26consumer_secret'
'consumer_secret%26consumer_key'
and others but i'm just shooting in the dark...

I know you said "B]oauth_consumer_key[/B%26B]oauth_token_secret[/B", and 'B]oauth_consumer_key[/B%26' .. but it also gives "invalid signature"

Am I missing something or misunderstanding oauth? (my nick is "alanw" for your reference)

devbobo

gyrus wrote:

ok I feel kind of stupid seemingly asking this again, but since I'm having trouble..

G'day gyrus,

No, you're not stupid

The php code I initially based my code on, has a bug (imo) or is at least doing something that isn't compliant with the spec.

The code urlencodes the entire signature after it's been constructed so B]oauth_consumer_key[/B%26B]oauth_token_secret[/B actually becomes B]oauth_consumer_key[/B%25%26B]oauth_token_secret[/B.

I asked the question over on an OAuth forum, but didn't really get the sort of reply I was after. So I have decided it's a bug and hopefully a fix will go out this week.

Cheers,

David

devbobo

this fix is live now.

gyrus

sweet. I tried it real quickly last night and it worked (I received values for both oauth_token and oauth_token_secret). thanks!

however, I'm trying the exact same code again, and I'm getting a response with empty values for oauth_token and oauth_token_secret:
specifically, I'm getting a response:

oauth_token=&oauth_token_secret=

is this a temporary glitch in the system, or a real change where I would need to modify the code?

gyrus

it looks like it was just a glitch. it works again now.

lildude

devbobo wrote:

G'day gyrus,

No, you're not stupid

The php code I initially based my code on, has a bug (imo) or is at least doing something that isn't compliant with the spec.

The code urlencodes the entire signature after it's been constructed so B]oauth_consumer_key[/B%26B]oauth_token_secret[/B actually becomes B]oauth_consumer_key[/B%25%26B]oauth_token_secret[/B.

I asked the question over on an OAuth forum, but didn't really get the sort of reply I was after. So I have decided it's a bug and hopefully a fix will go out this week.

Cheers,

David

Sorry about getting to this a bit late - I've been off getting married.

I'm not sure I agree with you David. I interpret the std (point 9.4.1) to say:

encode each of the params, concat with "&" and then encode the final concatenated string.

I don't interpret this to mean the "&" must be encoded twice and the examples given don't indicate the "&" has been encoded twice.

That said, if my interpretation is wrong and the "&" must be encoded twice, wouldn't it be "%2526" not "%25%26"?

Edit: Further testing seems to indicate the SmugMug endpoint doesn't even want the "&" encoded in order to work.

ie using "<oauth_consumer_key>&" in my getRequestToken request works, but the old method (and the method I interpret the STD to require) that used to work, "<oauth_consumer_key>%26", doesn't anymore.

I don't think this new behaviour is correct as "&" is interpreted in a URL as an argument separator, and in this case the "&" is not an argument separator for the endpoint, but a separator of the data in an argument for the endpoint (if that makes any sense).

lildude

Ignore me
Ignore me... I've just realised I was double encoding without realising it: PEAR's HTTP_Request encodes all POST arguments by default.

devbobo

lildude wrote:

Ignore me... I've just realised I was double encoding without realising it: PEAR's HTTP_Request encodes all POST arguments by default.

yeah, it's very easy to get tied up in knots with this stuff

lildude

Now for HMAC-SHA1 Fun
I finally got my head around the PLAINTEXT method and can get an oauth_token and oauth_token_secret for BOTH POST and GET requests to both the API endpoint (http://api.smugmug.com/services/api/php/1.2.2/) and the OAuth endpoint (http://api.smugmug.com/services/oauth/getRequestToken.mg) but I can't say I'm having the same luck when using the HMAC-SHA1 method.

So far my testing has been as follows:

http://api.smugmug.com/services/oauth/getRequestToken.mg

PLAINTEXT

GET: Success
POST: Success

HMAC-SHA1:

GET: Success
POST: Fail - Invalid signature

http://api.smugmug.com/services/api/php/1.2.2/

PLAINTEXT

GET: Success
POST: Success

HMAC-SHA1:

GET: Fail - Invalid signature
POST: Fail - Invalid signature

I'd like to concentrate on getting the OAuth endpoint working first and then I'll come back to the API endpoint (if need be).

For the OAuth endpoint testing, I'm using a modified version of the client.php file (attached) available from http://oauth.googlecode.com/svn/code/php/example/ (same code you're using David?) so that I can flip between using POST and GET. I've also corrected the OAuth.php file to correct the behaviour discussed above for PLAINTEXT.

Now this file is what provides the test results above.

Any ideas why using the HMAC-SHA1 method and POST is continually returning invalid signature for getRequestToken? (I've not tested any further yet).

lildude

Got it working
Woohoo!!! I got it working for BOTH the API and OAuth end points.

OAuth endpoint problem: My form was submitting an extra value because I assigned the submit button a name.

API endpoint problem: I was using the wrong endpoint and was also leaving off the other options passed to the API, namely Pretty and method, when calculating the signature.

Now for implementing OAuth support for all of my function calls.

Thanks for the useful extension David.