Hey guys I'm trying to use the Dailybooth api, and getting access to the user via oauth.. I'm very new to ruby/rails and this is my first time working with an api and oauth. Here's the thing though
if params[:code] #if the code is avaible, use the code
dailybooth.oauth_token(params[:code])
@oauth_token_ = params[:code]
session[:oauth_code] = @oauth_token_
else #else, attempt to use the session
if session[:oauth_code] #If session is set
dailybooth.oauth_token(session[:oauth_code]) #sign in using session
else #else, check if the params[:code] is set and use, or redirect to dailybooth authorize
if params[:code]
dailybooth.oauth_token(params[:code])
@oauth_token_ = params[:code]
session[:oauth_code] = @oauth_token_
else
#first redirect the user to the authorize_url
redirect_to dailybooth.authorize_url
end
end
end
#make request to the api
@info = dailybooth.get('/users.json')
if @info['error']
if @info['error']['error_code']
if @info['error']['error_code'] == 302 #if getting invalid token, request another token.
session[:oauth_code] = nil
@inf开发者_运维知识库o = "Getting Errorcode 302, invalid token."
#first redirect the user to the authorize_url
# redirect_to dailybooth.authorize_url
end
end
end
So, that is the index of my app. When I first go to the index, I'm immediatly transfered to dailybooth to authorize my account, after authorizing, dailybooth returns me to my site with a URL that looks like so "http://site.com/?code=XXX" and "dailybooth.get('/users.json')" goes to work, it actually get's the user information. but if I try to refresh, going to the same "http://site.com/?code=XXX" it'll say the token is invalid. Why is that? The token was just valid and now it's not working. Any suggestions? Is this an error on my end?
My guess is that the problem is you are storing the dailybooth OAuth Token and not the Access Token. Your call to dailybooth.oauth_token(...) probably generates an Access Token and you should be storing that, not the params[:code] (OAuth Token). Generally OAuth works like this:
- The user is redirected to the site to give your application access.
- The user is redirected back to your site with an OAuth Token giving you access to certain parts of the API or external site.
- You trade that OAuth Token in for an Access Token that you can use to access the API and site at any time.
- Once that OAuth Token has been traded in for an Access Token it can't be used again, but the Access Token can.
Check the dailybooth object, you can probably access the actual Access Token somehow (dailybooth.token or dailybooth.access_token maybe?). Make sure you store that access token in your session or database, and then use that access token upon returning to the page instead of the params[:code] that has at this point become invalid.
I cannot help you with Ruby as I've never used it, however I can add to the comment above what is the flow in OAuth 2 (which is definitely the preferred choice to use):
- The user goes to your site and needs to access functionality that requires the use of a Third-Party OAuth provider API (your site is Consumer and the Third Party is Provider and I will call them this way below)
- Consumer makes internal HTTPS request to the Provider to get unauthorized Request token.
- Consumer redirects the user to the Provider with the Request token it just received in step 2, in order for this token to be authorized by the user at the Provider's site.
- After the user authorize the Request token (eventually), the Provider creates Verifier String and redirects the user back to the callback with this Verifier String and the Request Token, which is very important. In fact, this is the part of OAuth 2, which identifies that the user has really authorized the token (the Verifier String).
- Consumer makes internal HTTPS request with the Request token and this Verifier String to get Authorized Access Token.
- At this point if the Consumer receive Access Token, he has the right to access the protected API with the user's permission.
Here is a good explanation of why the Verifier is important and added to the protocol:
http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/
精彩评论