FB Logout Flow: how to revoke user permissions? - facebook

I was having problems with my FB logout flow, and I think I have it. I ended up having to add an HTTP DELETE request to
https://graph.facebook.com/v9.0/[user-ID]/permissions?access_token=[access_token]
In order to revoke the user's permissions.
The problem I have is that now there's a popup every time it goes to the page that invokes this request (I use PHP's cURL library to invoke the request) asking to continue and whatnot. I click the "continue as" button, but the popup never goes away... it just turns to a blank screen.
Am I doing something wrong here? If I invoke the request without the access token, I get an error stating it needs an access token...

Related

Facebook API 4.0: How to avoid "This authorization code has expired"?

On my website I use the facebook javascript SDK to initialize and login the user, and later once the user has responded to the survey and submitted it on the website, i fetch the facebook user on the server side using facebook PHP SDK. This works great, except for the case when the user connects to my app then leaves the page open for a while, to later comeback and attempt submit the survey. If the user waits long enough, I will get the "This authorization code has expired" error on the PHP server side, i'm not sure how to solve this.
Is there some way to refresh the authorization code through javascript SDK? I assume it is generated on FB.init. The optimal thing would be if i could make a check before the submit to see if the authorization code is still valid, then if not i would refresh it and fire the submit event.
One way to solve this may be to use FB.getLoginStatus of the JavaScript right before the server call - it refreshes the Access Token and you can get it in the response:
https://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus

Can I always show permission dialog in Facebook application when user logins?

I'm trying to write application for user login to website via Facebook. When user is logging in, he's redirected to http://www.facebook.com/dialog/oauth/?client_id=APP_ID&redirect_uri=REDIRECT_URL&state=STATE, then sees confirmation dialog to use permissions and all goes well. But then FB somehow remembers this application and never asks for permissions confirmation again when user opens this url. Is there any way to always show this dialog? I could do it in Twitter, but couldn't found the answer for Facebook.
If you really want this for some reason, uninstall the app from the user's account with a HTTP DELETE request to /USER_ID/permissions using your app access token.
The next time they come back they'll need to re-authorise the app.
Otherwise, no, there's no way that I'm aware of apart from the reauthentication flow to force the auth dialog to appear, but bear in mind that the reauthentication flow may prompt the user to re-enter their Facebook password even if they're already logged into Facebook, so it adds extra friction to the process
Instead of showing the Facebook OAuth dialog, you could also show the user a page on your application that has some information about the Facebook account that is going to be used (picture/name etc), to log into it. That way, if they like they can choose to log out and re-authenticate or continue knowing they have the right account.

How do you renew an expired Facebook access token?

I am working from this reference, and trying to implement the OAuth protocol to allow users to log into my site via Facebook. However, Facebook's documentation is pretty terrible and it unclear in a few key parts.
It says that authorization takes three steps:
User authentication (redirect the user to https://facebook.com/dialog/oauth?client_id=...&redirect_uri=..., and expect the redirect_uri page to be called back with a code). Works great!
App authorization (handled by Facebook, etc). Works great!
App authentication (On the callback page, grab the code you get and call https://graph.facebook.com/oauth/access_token?client_id=...&redirect_uri=...&client_secret=...&code=.... The body of the response will include an access_token we need to do stuff)
I understand that with the access_token, I can call the APIs and such. But, what happens when it expires? I could get a new one, but by this point it will be many HTTP requests later, and I no longer have the code I used to get it in the first place. Do I have to store the code along side the access_token? Or, do I have to tell the user to log in again so I get a new code to get a new access_token?
Or, am I missing a key part here? I don't need an offline_access token, as I will only be polling data in response to user actions .
When the access_token expires, the user will be seen as "logged out" by Facebook. Your app will go through the same process as the first time, but the user may not.
If the user hasn't revoked access to your app, and the user is logged into Facebook at the time, the App Authorization process will take care of itself, with no actions required by the user, and you will receive a new access_token.
If the user hasn't revoked access to your app, but isn't logged into Facebook, they will be presented with a Facebook login at the App Authorization step. They won't be asked to give your app permission again, as Facebook knows that your app id is authorized by that user.
Finally, if the user has revoked access, then they will be presented with the original request for App Authorization, and you'll follow the original flow.
Essentially, you should consider the access_token as volatile, and not bother storing it, but using the access_token you receive as part of the user login process, which is happening behind the scenes all the time, and only involving the user when they log out of Facebook or revoke access to your application.
This is different than Twitter's OAuth with which you can store and re-use it.
From the Facebook documentation linked in your question:
Once the token expires, you will need to re-run the steps above to
generate a new code and access_token, although if the user has already
authorized your app, they will not be prompted to do so again.
When the access_token expires you will need to get a new one by going back through the same steps. The user will have to log in again and you will have to get a new code and in turn, a new access_token.

Facebook authentication and Ajax

I am building a Facebook application, and using the oAuth 2.0 protocol for authentication/authorization.
When a user first visits my app I am using the protocol and store the access token in order to make future requests to the Graph API. The problem occurs when the access token expires and the user is using ajax.
When the ajax request is sent I try to retrieve information from the Graph API using the access token, but since it expired I get a JSON saying the access token is invalid. Now, I can send a response back to the client saying the access token expired and on the client side I can redirect him to https://www.facebook.com/dialog/oauth to go through the authentication process again. However, since the whole process is in Ajax, redirecting the user will hurt the usability of the application.
Is there any other way I can use the protocol to get a new access token without needing to redirect the user's browser to get a new access token? Maybe something on the server side?
You just need to ask for the offline_access permission, then your access_token will not expire.
As Rafael notes, you can ask the user for offline_access and then the token should never expire. However, in practice, the access token does expire when a user changes their password or uninstalls/reinstalls your app, so you'll need to build a way for the user to reauthenticate themselves so you can update their token. I suggest redirecting them to a login page that should (ideally) just send them right back where you tell them to go without them having to do anything, and using deep linking to put them right back in your app where they left off.
I'm encountering this issue as well. One solution I came up with is as follows:
Create an async method called isAccessTokenValid()
Invoke isAccessTokenValid() before any method that will require FB interaction
If access_token has expired. save the current uri to the session, along with any form data entries (if any), and start the re-authentication process again.
Once the user has re-authenticated, bring up the stored uri.
This is a bit dirty, but I haven't seen a cleaner solution yet.

Facebook Connect Bug? (Post-Authorise URL Being Put in Window Instead of OnLogin Callback)

I have a ASP.NET web site which uses Facebook Connect for authentication - using the JavaScript API and the Facebook Connect FBML Button.
Here is the regular flow of events for a "Connect with Facebook" button click, when user isnt logged into Facebook.
Dialog is shown requesting user to login
Dialog requests permission from the user for basic info permission
The popup is closed
The callback function i supplied for "onlogin" is fired.
All good.
Now - here's what i think is a bug: the user is already authenticated to Facebook, but has not authorised my app.
This is the flow:
Dialog is shown requesting permission from the user for basic info permission
The URL for the popup changes to http://rootofmysite.com/?installed=1&token=3e3920d309
The user is left wondering what is going on, and the onlogin callback is NOT fired.
So, the popup window is replaced with my original site, and in the querystring is the OAuth token? This looks to be the "Post-Authorise Callback" URL which used to be in the Facebook Application Settings - but has been removed. Anyway, i dont care about this URL - i request permissions/authorization using the client-side JavaScript API, as im a sure a lot of people do.
I understand the user is already authenticated, so they wouldn't need to login again, but what i dont understand is a) why the "onlogin" event handler is not called, and b) why on earth are they replacing THEIR dialog with my site and the OAuth token in the url?
At the moment, i am trying to do a "creative workaround" where i detect this URL and close the popup and call my "onlogin" handler manually (what Facebook SHOULD be doing).
Still, quite dodgy.
EDIT
It's another bug peoples. Please vote for it so they fix it.
It's a (unconfirmed) bug.
http://bugs.developers.facebook.net/show_bug.cgi?id=12260
Hopefully it gets more votes so it gets fixed - vote people!
In the meantime, i am (attempting) to employ the following 'creative workaround':
Add logic to my Default.aspx page to detect that URL they are redirecting to in the popup.
Redirect to my page, FacebookInboundAuthorization.aspx, preserving querystring.
On load of that page, register some JavaScript to close the popup and manually fire the "onlogin" event handler for my button.
EDIT
To clarify my above, i didnt mean "vote people" as in to vote for my answer here, i meant vote for the bug on Bugzilla (so that FB accept it as an issue and fix it).