I have an Instagram feed on a site which fetches the latest 25 posts of their IG account. This is done with a basic jsonp request, using the standard api.instagram.com call. Nothing too exciting or ground breaking.
While the site's been in development, the access_token expired 3 times. I should have really heeded those warning signs. Since the site's gone live, it expired 4 times yesterday alone.
I know in the docs it tells me not to assume the token lasts forever, but surely they don't define "forever" as 2 months?
What theoretically could be causing the access_token to expire so often? My only idea is that they're using Juicer (a 3rd party social aggregation service) which could be hammering the API?
I also thought because the app was still in sandbox it would have tighter restrictions. That can't be the case because when I try to submit it for approval, I get denied:
If you are a developer and you want to display Instagram content on your website, then you do not need to submit your app for review. By using a client in sandbox mode, you can still access the last 20 media of any sandbox user that grants you permission.
(Surely I'm not getting penalized because I'm requesting 25?)
All out of ideas otherwise. Am I doing anything inherently wrong or is this just Instagram being exceedingly strict?
All help appreciated,
Tom
Related
I have a headless Facebook app that we've been running for 4 years. It is a bit unique in that, a) it has no user display b) it isn't available on the public internet it is hidden behind firewalls.
I use the standard Facebook Login Page during configuration of our app merely to get a permanent access token and authorize permissions. The only permissions I need are publish_actions, publish_pages and manage_pages.
I've tried to submit the approval form for this app to Facebook and get complete rejection because I haven't provided screen shots of what they see when they log into the app. I can't do that because as I said, it's headless and not available on the public internet. The response I get from the reviewers is completely canned with no thought on their part as to the restrictions of my app.
Does anyone know what I can do to get this app approved? As I mentioned, we've had this app on Facebook for 4 years prior to April 30, 2015. Is there someone I can talk to at Facebook? I've tried to explain the situation in the submission form, but obviously that didn't work.
I'm using django-facebook on an app. Users can publish open graph actions from the application, but I'm running into problems with expired oauth tokens since moving away from offline_access.
I'd like to check token validity (and update it, if necessary) without a server-side, blocking, call.
My first thought was to pull the current access_token from the javascript library and then save to the database whenever they hit the page - but that overwrites the longer-term one with a 2 hr one; not very good.
Something more like what Facebook describes in their blog post could work, but, again, I'd like it to be non-blocking. Also, if the user is currently logged into the app, I'd like to not present them with a dialog just to renew the token.
django-facebook docs note that version 4 supports "Automatic reauthentication for expired tokens," but I don't seem to be triggering that in the app.
Either specifics on how to get this to happen automatically with django-facebook would be great, or, alternatively, some advice and guidance on standard/best practices here would be very helpful. Thanks!
(Apologies for any naïveté here, I'm an occasional FB developer and frequently find that I'm lagging behind changes to the Facebook API.)
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.
I have a Facebook application that does scheduled posts on fan pages.
To do this, the app acquires an OAuth token to use for posting on the page. To get this token, the user needs to visit the app. However sometimes Facebook invalidates these tokens, at least if the user changes their FB password and it seems in some other security-related cases too.
When this happens, the app will fail to post the scheduled post and users are unhappy. How should I resolve this? I could email the users when their token expires, but how would I detect the expiration? Given I have 100,000+ users, it would be expensive to poll the tokens very often.
Well do directly answer your question, here you go: Facebook Debugger
Enter the Access_token there to check its validity and other info. But I know that wouldn't solve your problem in general. I can help you in the right direction.
You see token validity is affected by the permissions you asked from the user. There is this offline_access permission that gives you an access token that won't time-out, not the regular hour-long tokens. And I'm sure you know this since you're already able to schedule user posts.
Unfortunately, offline_access is now deprecated by Facebook (see this link). From now on, Facebook will give us 2-month access_token by default, even without the permission. From then on, we'll need to "refresh" or extend the access token. Read more on that link.
And about your problem in use changing password, logs out, etc, Well Facebook has its own dedicated blog post about it as well, see here.
If you wanna take the path of checking token validity yourself, you can setup a CRON that runs every hour or everyday (depends on you), and do a quick API call for each token (/me). If it fails or generated an error, token expired.
Much better if you'll do it every minute: 10 to 20 tokens to check, so it wont have a heavy burden on your server doing 100,000+ calls in one execution.
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.