stackmob oauth authorization problems

[nib]

I cannot get stackmob access working.

I have tried following the content of the stackmob tutorial (http://help.gotiggr.com/getting-start..., but I cannot get access to my own stackmob repo. I get json response: {"error":"Invalid OAuth credentials or signature: signature_invalid"}.

I have verified, using firebug that the my getAuth is called and that the request is sent to stackmob with Authorization Header as expected. I can see my key, but nonce and signature etc. are different from what I see using cURL (and the test console on the stackmob site). When accessed using cURL I get expected json back.

It may be something in the stackmob end, but I wanted to ask if, perhaps, you did something to oauth (or related functionality) in the last release? I will continue digging into whether the oauth headers are as expected.

The project is 152b0eef-8066-471c-900e-18862bf4277b, and if you click "register" button on the first page, the REST is called while loading the next page. Perhaps it is sitting on the wrong event, so on the next page, there is another button "Reload" that makes the API call.

Btw. stackmob is going to release a much desired oauth2 and ACL functionality in june presumably (http://support.stackmob.com/entries/2...) will you follow suit and update the example?

[nib]

I notice that the oAuth lib (http://tiggzi.com/resources/preview/l...) has been touched a week ago:

Date Thu, 24 May 2012 07:58:55 GMT
Last-Modified Fri, 18 May 2012 08:56:44 GMT

Could that be causing problems. I did consider if I could replace it with some other lib (e.g. the one used here: https://groups.google.com/forum/#!top..., I am not sure I could modify the datasource accordingly quicly.

Cheers,
/)/ikolaj

[nib]

I have played a little further and see something that may be of help, of may be me not properly understanding the tiggzi proxy.

The oauth headers at used when I apply the tiggzi proxy, and I get the json back about invalid credentials.

When I do not use the tiggzi proxy I cannot see that oauth headers applied in firebug, and then I get an 403 Forbidden back which seems reasonable.

So why are the oauth headers not applied when not using the tiggzi proxy? And could the tiggzi proxy be mangling the headers sent?

[maxkatz]

I just tried the app which is based on this example: http://help.tiggzi.com/getting-starte... and it works.

This is how I calculate the header:
code

function getAuth(requestMethod, url){

Code: Select all

 if (url == null) { 
    url = 'http://api.mob1.stackmob.com/list'; 
 } 
 console.log(url); 

 var key = 'xxxx.....'; 
 var secret = 'xxxx.....'; 

var accessor = { consumerSecret: secret, tokenSecret: "" };

Code: Select all

 var message = { method: requestMethod, action: url, parameters:OAuth.decodeForm("") }; 

 message.parameters.push(['oauth_timestamp', OAuth.timestamp()]); 

message.parameters.push(['oauth_nonce', OAuth.nonce(17)]);
message.parameters.push(['oauth_signature_method', 'HMAC-SHA1']);
message.parameters.push(['oauth_consumer_key', key]);

Code: Select all

 OAuth.SignatureMethod.sign(message, accessor); 

var auth = OAuth.getAuthorizationHeader("", message.parameters);
//console.log(auth);

Code: Select all

 return auth; 

}
/code

[nib]

That is what I have too, except key contain my public key and secret my private key.

Could it be that the example contains an old version of the oauth.js whereas my tiggzi project, which was created more recently contains another? Or similar?

I am attaching a screen shot of my rest service setup (which is next step after auth, which seems identical...):

[nib]

if you could make the example URL public, I could snoop around and look for differences ... (or is it connected to an account at stackmob which could cause payment if there is too much traffic?).

[maxkatz]

Here you go.. let me know when done: http://tiggzi.com/view/11122fee-5707-...

[nib]

Thanks, that did the trick!

It killed all my ideas for how the problem could be in your part of the chain, so instead I suddenly realized that I had an extra parameter on my service, _expand=1, which caused the signature to be wrong.

Great service-level you have, I push and recommend you here and there