Ok so i go through the handshake and get the request token... then i send the user to the authorize login page. It then shoots back to my app and I request an access token. It comes back with the UserID an oauth_token and an oauth_secret_token...
the oauth_token looks similar to the feed_token used here :http://josephsmarr.com/2008/10/01/using-netflixs-new-api-a-step-by-step-guide/
I have tried every possible permutation of secret tokens, access tokens and, API keys (except the right one) and i keep getting a 403 forbidden when i try to request data for a user.
What the heck am I missing? Can someone give me an idiots guide to this please?
Normally, you need three things.
* the consumer key and shared secret (the API key and the secret you got when you signed up),
* the user's id
* the user's OAuth Token and OAuth secret
You can try the OAuth test page (available under the Resources tab or by going to http://developer.netflix.com/resources/OAuthTest ) and plug in the values to make sure it works and the URL your using matches up against what you're sending.
A bit of offline sleuthing showed two things. One: he's using a C# library. This is important because .Net url encodes things to lower case wher the OAuth standard is uppercase (e.g. while syntactically the same, for OAuth's signature generator "%3d" and "%3D" are very different).
Two: unfortunately, shaggyb wasn't able to consistently get the error. This also points to odd characters or encodings appearing in the URL as random values change. (e.g. you might have "123%3D" appear as a signature once, and the next time the signature is set to "4567".)
If at all possible, I really do recommend using a library, preferably one of the libraries listed on the Resources page or an actively maintained OAuth library. The authors do want to get this right and do appreciate hearing about odd bugs like these. At the very least, let me know about any bug and I'll pursue it with the authors.
Ok so i go through the handshake and get the request token... then i send the user to the authorize login page. It then shoots back to my app and I request an access token. It comes back with the UserID an oauth_token and an oauth_secret_token...
the oauth_token looks similar to the feed_token used here :http://josephsmarr.com/2008/10/01/using-netflixs-new-api-a-step-by-step-guide/
I have tried every possible permutation of secret tokens, access tokens and, API keys (except the right one) and i keep getting a 403 forbidden when i try to request data for a user.
What the heck am I missing? Can someone give me an idiots guide to this please?
Thanks
Message edited by shaggyb 3 years ago
John Haren – 3 years ago
A 403 should be for QPS overages, not auth errors (those should be 401s)... try putting a little delay in there, and see if that works.
JR Conlin – 3 years ago
Normally, you need three things.
* the consumer key and shared secret (the API key and the secret you got when you signed up),
* the user's id
* the user's OAuth Token and OAuth secret
You can try the OAuth test page (available under the Resources tab or by going to http://developer.netflix.com/resources/OAuthTest ) and plug in the values to make sure it works and the URL your using matches up against what you're sending.
shaggyb – 3 years ago
so im already doing a delay between requests. Also, if I want to request a users rental history for example then I need a url like this
http://api.netflix.com/users/T1G.NK54IqxGkXi3RbkKgudF3ZFkmopPt3lR.dlOLC898-/queues/instant?feed_token=T1v23xnWpcYnhhkIsQ_iyASermOnPjgFKP77FdaXGkWEqUvwrPAjTeVHlgLpMlx2FF&oauth_consumer_key=k5mds6sfn594x4drvtw96n37&output=atom
Note: that url is taken directly from Joseph Smarr's tutorial page. It works for his feed_token and userid and consumer key.
How does someone get the values necessary for this feed to work?
Anu – 3 years ago
You can get a user's feed urls using resource - users/userID/feeds
JR Conlin – 3 years ago
A bit of offline sleuthing showed two things. One: he's using a C# library. This is important because .Net url encodes things to lower case wher the OAuth standard is uppercase (e.g. while syntactically the same, for OAuth's signature generator "%3d" and "%3D" are very different).
Two: unfortunately, shaggyb wasn't able to consistently get the error. This also points to odd characters or encodings appearing in the URL as random values change. (e.g. you might have "123%3D" appear as a signature once, and the next time the signature is set to "4567".)
If at all possible, I really do recommend using a library, preferably one of the libraries listed on the Resources page or an actively maintained OAuth library. The authors do want to get this right and do appreciate hearing about odd bugs like these. At the very least, let me know about any bug and I'll pursue it with the authors.