Simply put:
You need the API Key (consumer key) and secret to talk to anything.
You need the user's Auth token and auth secret to do anything on the user's behalf.
You need the User ID to identify the user you want to do stuff for.
You need to save all of these somewhere secure so that someone else doesn't get at them (so storing them in javascript is probably out, but storing them to the Facebook Data system is fine.)
The user only has to grant your app access once. (Well, unless you change your app key, or they drop your app's access or something, but that's to be expected.)
You don't need to save the request_token or secret beyond the Authorization process. (So, once you've used it for the user login and then used it to get the auth_token, it's worthless. One quick note, make sure you've got that in the right order. Send the user to the login first, then request the auth token. The request token is only valid for one go at that, so if you get them out of order, or the user says "no", then the request token is no longer valid.)
Honestly, the best guide for figuring out how this works is Joseph Smarr's guide. Look on the "Resources" page for a link to that.
It's a bit confusing at first, but once you grok it, it makes sense.
Thanks very much! I kept reading the docs over and over shaking my head in agreement like it made sense. Then I would go and try to implement it and wonder if I read it wrong.
I was just scared that the auth token needed to be fetched over and over like a request token.
So... After hours of reading and looking diagrams, what then heck are we supposed to save?
So I direct the user to the login, blah blah. The success url comes back with request_token and request_token_secret, and *oauth_token*.
Do I save that?
Do I immediately turn around and exchange it for an access_token?
Do I save that?
I obviously gleaned that I save the user_id... but there's not really a "hey, save these for later because you're always".
How many times does the user have to use oauth/login?
Thanks for anyone who responds to alleviate our hair-pulling frenzies!
Message edited by David Engfer 3 years ago
Tags
JR Conlin – 3 years ago
Simply put:
You need the API Key (consumer key) and secret to talk to anything.
You need the user's Auth token and auth secret to do anything on the user's behalf.
You need the User ID to identify the user you want to do stuff for.
You need to save all of these somewhere secure so that someone else doesn't get at them (so storing them in javascript is probably out, but storing them to the Facebook Data system is fine.)
The user only has to grant your app access once. (Well, unless you change your app key, or they drop your app's access or something, but that's to be expected.)
You don't need to save the request_token or secret beyond the Authorization process. (So, once you've used it for the user login and then used it to get the auth_token, it's worthless. One quick note, make sure you've got that in the right order. Send the user to the login first, then request the auth token. The request token is only valid for one go at that, so if you get them out of order, or the user says "no", then the request token is no longer valid.)
Honestly, the best guide for figuring out how this works is Joseph Smarr's guide. Look on the "Resources" page for a link to that.
It's a bit confusing at first, but once you grok it, it makes sense.
David Engfer – 3 years ago
Thanks very much! I kept reading the docs over and over shaking my head in agreement like it made sense. Then I would go and try to implement it and wonder if I read it wrong.
I was just scared that the auth token needed to be fetched over and over like a request token.
Thanks once again!