I am just getting into adding Facebook opengraph into my app. I want to get certain graph attributes from the user, but it needs to be done continuously, even when the person is not on the site. Basically the app requires a background process that fetches content from the user's Facebook activity feed.
So my first step was to store the user's access token in a table and regularly run a cron task. However I discovered that Facebook is moving towards deprecating offline access. I know this may sound stupid to those of you who are familiar with this, but I am not sure what this means, and wanted to confirm.
My understanding is:
Beginning in May when Facebook completely switches to offline access deprecated mode, even if I store a user's access token, it will expire in 60 days.
So I could re-store the user's access token everytime she/he signs into my app
But if the user doesn't sign back into the service for more than 60 days, it's all over and the background task won't be able to crawl content from the user anymore.
Which means, for example if it was a newsletter service that sends users useful information based on the activities, if I don't ask them to sign in (they may visit my site to check out the content but the site doesn't require them to sign in to view content), the engine will stop operating after 60 days and the user will just forget about it.
Is this correct?
Check out: https://developers.facebook.com/roadmap/offline-access-removal/ It has all the answers.
But basically yes. Offline_Access is coming to an end.
Related
We are using "Sign In with LinkedIn" in our website and we are in the process of adding Facebook Login. I was asked to figure out how to keep the info from the users updated after they login (even if they don't come back to the site) and I'm not sure whether this is possible, or for how much time we are able to access their profile info.
If a user logs in and changes his profile info a month later is it possible to know it even if they don't Sign In again? Could I run a cron job that uses Facebook and LinkedIn APIs to update the users data?
Note: The following answers are related to Facebook API only (I've never used LinkedIn API before, but I'm pretty sure the answer can give a brief overview about the problem).
If a user logs in and changes his profile info a month later is it
possible to know it even if they don't Sign In again?
Yes. It is possible to change a user's profile info later, without signing in again. Actually, it depends on the time of the info you're willing to access. If it is a publicly available info (that doesn't need an Access Token), you can easily fetch it from the Facebook API (assuming you are storing the user ID or username in your application when a user first logs in) whenever you want.
However, if it is something which requires an Access Token, then you might need to ask user to login again (since a User Access Token expires within 2 hours). You can also generate a Long Lived User Access Token, which typically expires in 60 days. This means that you can request for a user's info from the Facebook API, without needing them to sign in again, within those 60 days.
Could I run a cron job that uses Facebook and LinkedIn APIs to update
the users data?
Yes. You can create a Cron Job using your application to fetch the updated info just like I mentioned in the answer to your previous info. Facebook used to provide a similar functionality few years back using a special offline_access permission, but it has been deprecated and cannot be used anymore.
Several alternative methods to it (for example: this post and this post) can be found by a simple Google search and almost all will discuss the method which I just mentioned in the answer above. Take a look at the answers to this post for more info on the creation of a Cron Job for Facebook API.
Basically #Rahil gave a good explanation what you can do. It's important to exchange the short-lived Access Token to a long-lived one, ideally right during the signup process.
What info you can query/update is determined by the permissions you request during the Login, see https://developers.facebook.com/docs/facebook-login/permissions/v2.0
A functionality that wasn't mentioned before are the so-called Realtime Updates. Have a look at the docs here: https://developers.facebook.com/docs/graph-api/real-time-updates/v2.0
Basically you need to setup a service which is reachable for Facebook, and FB then will send a request to this service with the info which field/connection was updated by which user (actual data/the changes themselves are NOT send). You then need to use this info to form a Graph API request and gather the actual changed data yourself.
Be aware that not all fields/connections can be accessed and used by the Realtime Updates API.
I have a site that logs in using Facebook. The first time a user logs in, they get a pop up from Facebook explaining all the parts of the user FB profile my site will have access to. After accepting once, though, they don't get this pop-up on subsequent visits. Is there a way I can ensure that the user always sees this popup?
Update:
I'm trying to find a way to do this during development, so that I can see the list every time. I don't really need this in production.
they see it because it's the standard OAuth workflow to accept the terms of the application they are authorizing through facebook. Once the auth is complete, they are sent directly through, no reason to ask them for auth over and over.
EDIT:
Based on your update, the list is visible through your application settings in Facebook. you can use facebook's api to get these users.
You can build a "Fake Login" - there you can show your terms again. So your clients got a better feeling. ;-)
First let me introduce the problem. I have site where I want to allow users to login using their Facebook account. Also I want to have possibility to post on users wall and access his email. I created Facebook app and every time not logged user comes to login page he clicks on Facebook button and gets to auth dialog of application where he must allow getting his email and on next screen allow posting on wall. To this dialog user gets with link which contains scope=email, publish_stream.
First question: When user clicks do not allow to post on wall, next time he uses this link he must again do that. Shouldn't Facebook remember this? I thought that I should not give the scope in link and use application setting where on permissions page a choose extended permissions. But these permissions are never asked for. Even when I enable referrals.
Second question: Is using FB application for this right? Should I not use fblogin?
Thank you.
When user clicks do not allow to post on wall, next time he uses this link he must again do that. Shouldnt facebook remember this?
No – because then there would be no way to ask a user for an extended permission once they’ve declined it.
Of course it might be annoying to the user to see that dialog asking for posting permission every time again when he just wants to login to your page.
That’s why Facebook themselves advise you to only ask for permissions you actually need for the current task. To provide the ability to log in to your site, you only need basic data and maybe email – so only ask for that, when the user is just logging in.
And then, when you come to the point where the user actively wants to share content through your app – then check if you got the necessary permission already, and ask them for it if it’s not present (by calling the auth dialog again, this time with the extended permission set in the scope parameter).
That way, it’s clear to the user why he gets asked for that permission at this point, and he doesn’t get hassled about it time and time again if he just only tries to log in.
I thought that I should not give the scope in link and use application setting where on permissions page a choose extended permissions. But these permissions are never asked for. Even when I enable refferals.
For these settings to have any effect, the connect to your app must happen in a way that actually triggers Authenticated Referrals. Doing the login by yourself in your app logic does not trigger this way of authentication.
I'm aware that there are many questions about Facebook access-tokens and the grief they cause, but despite much experimentation and reading many frustratingly vague blog articles (FB and otherwise), I'm still struggling to get a clear answer to my needs. Let me succinctly break down my process so far:
I am creating a site that, server-side, needs to pull the posts/statuses from a single Facebook Page
I am an admin of that Facebook Page
I have created a Facebook App
Using the Facebook Graph API Explorer, I've generated a short-lived key, connected to my app and my account, that grants permission to my account to view the access-tokens for my pages
I've converted my short-lived key to a long-lived key (60 days) ala scenario 4 from this
And here's where I am stuck. My 60 day key works fine for my server to pull the info needed from the page, but as far I can tell, there's no way to programmatically extend that 60 day key. I also do not know of a way to generate a new short-lived key without manually going to the Facebook Graph API Explorer and creating one.
Since it is my server making the requests to the Facebook API and not a user-based system (where I could easily request that a user authorize the Facebook app again), this creates a very clunky system. Since Facebook deprecated offline_access, is there really no permanent way to have my server pull info from my own page? Will I really have to create a new key by hand and manually update my server with it every 60 days?
Or is there something I'm missing?
Update:
The step-by-step guide that was previously found here has been migrated down into its own answer.
These are the steps that were previously in the question - they have been migrated to this answer.
Having found that it is possible to generate a Facebook Page Access Token that does not expire (with help from #Igy), here is a clear, step-by-step quide for all those looking to the same:
Make sure you are the admin of the FB page you wish to pull info from
Create a FB App (should be with the same user account that is the page admin)
Head over to the Facebook Graph API Explorer
On the top right, select the FB App you created from the "Application" drop down list
Click "Get Access Token"
Make sure you add the manage_pages permission
Convert this short-lived access token into a long-lived one by making this Graph API call:
https://graph.facebook.com/oauth/access_token?client_id=<your FB App ID >&client_secret=<your FB App secret>&grant_type=fb_exchange_token&fb_exchange_token=<your short-lived access token>
Grab the new long-lived access token returned back
Make a Graph API call to see your accounts using the new long-lived access token: https://graph.facebook.com/me/accounts?access_token=<your long-lived access token>
Grab the access_token for the page you'll be pulling info from
Lint the token to see that it is set to Expires: Never!
That should do it. You should now have a Facebook Page Access Token that doesn't expire, unless:
You change your Facebook account password
You lose admin access for the target page
You delete or de-authorize your Facebook App
Any of these will cause the access token to become invalid.
If you are getting (#100) Tried accessing nonexisting field (accounts) on node type (Page), go to the Access Token Debugger, copy the value of User ID, and use it to replace the "me" part of the URL in step 9.
This is covered in the Offline Access deprecation document
Use the 60-day token for the page admin to retrieve a Page Access Token (via /PAGE_ID?fields=access_token or /me/accounts) - the Page access token will not have an expiry time
An approach that works in 2019
I was recently trying to achieve something similar (to the use case described in this thread), but I wanted to make sure to respect Facebook's current policies, so I did a little research and here I'm sharing what I found.
My use case
So, as I said already, my use case is very similar to the one described here; that is:
I'm doing some work for a school district.
They are using a software tool to manage pretty much everything that relates to school transportation.
That tool allows them to send email notifications (to subscribers) when they publish bus delay alerts and school closure alerts.
A lot of people in the community follow the organization on their Facebook page, and that's the only place they look for those alerts.
So an employee of the organization has to manually publish each notification on the Facebook page (in addition to creating it in the transportation software). Moreover, those notifications eventually expire (or are simply deleted before they expire), so the employee has to go back later on to delete them manually as well.
It's a waist of time, so what we are trying to do here is to develop as simple system that periodically polls the software tool's database for new (and expired) notifications and update them (i.e. add and remove) on the Facebook page.
This is, in my view, a legitimate use case, but I wasn't sure how to implement it in a way that's in line with Facebook's policies.
The accepted answer
I followed the steps of the accepted answer and it worked, except that things appear to have changed: now, even though the generated page token does not expire, access to data does expire after around 60 days. You will see that as well if you follow the procedure and inspect the page token in the FB Token Debugger Tool.
Besides, the fact that the generated page tokens are tied to the user account is also unfortunate, because if the user updates his/her password, then the page token also gets invalidated.
How to do it in 2019
After several hours of research, I stumbled upon the following Facebook documentation article: Business Login for Direct Businesses.
It turns out that it is now possible, following the steps described in the above article, to generate a page token that is not associated to any particular Facebook user account and which will not expire (unless the FB App gets deleted or the underlying application token gets deleted, you know...)
So here are the steps and the most important parts:
You need a Business Manager account.
Verification will be required and a digital contract will have to be signed.
You need to add the target Facebook page to that account.
You need to create a Facebook App, and transfer that app to the same Business Manager account as well.
The app will have to go through Facebook's review process, because the following permissions will be needed: manage_pages and publish_pages.
Important note For the posts made using the generate page token to be visible to users other than the application administrators, that app will need to have been published and approved.
You may still experiment with the concept without submitting for review, but the posts won't be publicly visible.
In the Business Manager account (only after your app and page have been added to the account), you need to create what's called a System User, and give that user admin role (or permissions) to the target Facebook page.
A system user is owned by the Business Manager account, and isn't tied to a specific user. My current understanding is that one major use case for a system user is programmatic access to Facebook's Graph API (just what we need).
Then, for that system user, you need to generate a access token (which will be never-expiring). You will be prompted to select for which app. You will then select your target app.
You will then need to use the generated app token to generate a page token, which will also be never-expiring. The procedure is described in this article as:
GET /<PAGE_ID>?fields=access_token&access_token=<SYSTEM_USER_ACCESS_TOKEN>
That's it.
That token will never expire, and it won't be tied to a particular Facebook user, so it's exactly what we need!
The last part is to make sure that your Facebook app gets approved by Facebook. It's in fact the most important part, because the whole procedure is worthless if people don't see our posts.
I wanted to know for sure that I could rely on the above procedure to build something for my client without Facebook rejecting it in the end, so, beforehand (i.e. before starting to work on my client's project), I went through the whole process of creating a page, an app, a Business Manager account, etc. I verified my business. I submitted my app for review. In my request, I was very specific about my use case and emphasized that the app was for "self-use" (i.e. that the organization is developing an app for itself, not for other Facebook users). I got approved without less than 24 hours.
A few other notes about the app review process:
I had to select a platform for the app, so I selected website.
I had to indicate why the app needed the two permissions and how it was going to use them.
I had to indicate why the reviewer would not be able to sign into my app and try it (i.e. because the app will be used by a worker process).
For the mandatory screencasts, I simply presented manual operations in the terminal using the curl utility (to generate the page token and make posts to the Facebook page). I also showed how I was using Business Manager to link the system user to the page and generate a token, and so on.
Again, I was very specific about my use case, and I think that that helped.
I hope this information will be useful to people with similar use cases.
Many thanks to #redhotvengeance for step-by-step guide.
After some time, now there is clearly described in Facebook documentation:
https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension
Extending Page Access Tokens
Apps can retrieve a page access token from Page admin users when they
authenticate with the manage_pages permission. If the user access
token used to retrieve this page access token is short-lived, the page
access token will also be short-lived.
To get a longer-lived page access token, exchange the User access
token for a long-lived one, as above, and then request the Page access
token. The resulting page access token will not have any expiry time.
You can also copy and past from the app dashboard on facebook.
The steps:
Go to https://developers.facebook.com
Select your app in the top right corner of the page
(pic of what it looks like)
Click on Messenger from the options on the left (it will go to setting automatically) (pic of what it looks like)
Go to the "Token Generation" section in the page. Select what page you want to generate the token for. (pic of what that section looks like)
The copy and past your page token where ever you need it.
Keep in mind that while in theory your token won't expire, that it is directly tied to what ever facebook account your logged into. So say you change your password or you remove the permissions from between your account and your app then your token won't be valid any more.
I have an application that used to use offline_access, which obviously needs changing since that's going away.
We use this permission to publish messages to the facebook wall of a user when they interact without our backend through any number of APIs. We have a website, several mobile applications on iPhone, Android, Blackberry, and Nokia phones that connect to the application, as well as a desktop application that interfaces with hardware devices and all of these can cause the backend to attempt to publish to facebook, but only the website allows the user to make the initial authorization with facebook.
From what I understand, using server-side authentication gets 60 day long tokens, and the only way to get new tokens is to redo the authentication process which assuming the user hasn't changed password, is logged into facebook, and hasn't de-authorized the application will appear as nothing but a series of automated redirects.
Is there any other way to do this? For example, what exactly does fb_exchange_token do? Is it applicable in this case or does this ONLY apply to tokens received via the javascript API?
Is there anything we can do for these non-website user interfaces aside from incorporate the native facebook APIs and do the same thing for as the website?
Attempting to use fb_extend_token was pretty fruitless. Rerunning the standard authentication returned the same token but with a fresh 60 day expiry time. Doing it again a short while later didn't extend the token. I'm hoping this means I can only do this once a day, not once per token.
Since I was using the server-side flow and the keys would never be seen by the user I was able to rework my app slightly to use my APPLICATION token. These keys belong to your app and allow you to use the API on behalf of a user for as long as they haven't revoked their permission. The user authorization tokens can expire, but as long as the user hasn't explicitly removed your app from the apps they've allowed, your token will continue to allow you to post to the wall using a /user/ URL, the /me/ URLs won't work because your token is bound to your app.
I believe once the deprecation of offline_access is complete, obtaining/exchanging access tokens is the only way to do what you need.
Anyone who had offline access before the deprecation will still be able to use your application normally, for 60 days at least. Once this period is over, you have to re authorize users and extend their access tokens for another 60 days. To do this you have them log in, and authorize your app (if necessary). Then you extend their access token using fb_exchange_token, so it is good for 60 days.
I'm sure you have seen it, but it's all outlined in this article, more specifically the section about previously using offline_access. I also found this post useful for doing an upgrade. Here is another link that further details how to deal with invalid tokens.