In the Graph API, which is the "permission to install custom tab"? - facebook

Our app installs apps (or "tabs") to our users' Facebook Business Pages. Our code has been running nicely for many years, but as is usually the case with Facebook, things break all the time. Because, well, Facebook.
Some of our recent installation attempts are now failing with an error message we've never seen before:
(#2069016) This page does not have permission to install custom tab
As far as Google is concerned, this Stack Overflow question will be the first instance of that particular error message on the internet... So, I don't know what to do.
Any thoughts on what could be wrong?
For reference the page access tokens we're using have the following scopes (verified just now):
user_friends, email, read_insights, publish_actions, manage_pages, pages_show_list, publish_pages, business_management, public_profile

According to the change log, this is a 90 day breaking change, https://developers.facebook.com/docs/graph-api/changelog/version2.11/#gapi-90-pages
/page/tabs — Creating custom tabs with POST operations will only be available to Pages with 2000 or more fans, or pages managed by whitelisted apps. Existing custom tabs will be unaffected.
90 days in relation to the release of API v2.11, which was on November 7, 2017 - so you're starting to see the effects now.
This sounds as though the page tab add dialog was not affected (at least to me, I have not checked yet) - so presenting your app users with the dialog could allow them to easily install the app on their pages themselves, maybe give that a go. You can call it either via the JS SDK's FB.ui, or by redirecting the user to https://www.facebook.com/dialog/pagetab?app_id=YOUR_APP_ID &redirect_uri=YOUR_URL
https://developers.facebook.com/docs/pages/tabs#adding

As CBroe suggests, installing a page tab using the redirect method still works.
Edit: sadly they've closed this loophole too

The Page Tabs reference page states (emphasis added):
You can only create tabs on Pages that have 2000 or more fans, or if
you are an app developer with Admin privileges on those Pages.
So, if you're in the fortunate situation in which you personally have admin access to the page (e.g. you created the page, the page owner granted you admin access, etc.), then you can still install apps even if it has fewer than 2000 fans.
I believe this exception is provided to enable developers to, well, develop apps (duh). However, this same ability allows us to install production apps to live pages.
Note: My experience with this workaround has been hit-and-miss. It always works for me, but it doesn't seem to work well for other devs at our company. I have a theory for why this seems to be the case. Experimentation suggests that there may be another requirement - it looks like you might also need to have admin privileges on the actual app (Page Tab) you're attempting to install.

I have the same problem but I have detected that all the fanpages are blocked with less than 2000 followers I like that this is a problem or that sometimes it can and does not have less than that amount of followers

Related

Sitecore Social Connected will not connect with Facebook as publish_stream is deprecated

I am trying to connect Social Connected to Facebook using Sitecore 8's (rev 5) Social Connected functionality (we are unable to use Komfo for budget reasons) however i've had a few issues. I was following this walkthrough from the Sitecore documentation site.
I was getting this error when trying to connect a Facebook account:
"Invalid Scopes: read_stream. This message is only shown to developers. Users of your app will ignore these permissions if present.
Please read the documentation for valid permissions at: https://developers.facebook.com/docs/facebook-login/permissions"
So I went ahead and did some reading and found this Stack Overflow question
which from the information there I was able to find that the particular permissions that Sitecore is asking Facebook for are deprecated.
From there I changed the permission from publish_stream to publish_actions and was able to give Sitecore the permissions it needed in Facebook. The problem is that Sitecore wanted this to be done in the browser window it provided, and so it did not acknowledge that the permissions were set in Facebook, even though they were.
I then tried to manually add a social media account from a template, hoping to input the data it would need manually now that it had the appropriate permissions. However after doing this Sitecore then started to throw an error when adding other social media accounts:
"The Social Connected Module is not configured.
There are no social networks available with applications that you can use to create an account."
Social connected is in fact configured, and before making these changes I was still able to add other social media accounts. Recreating the Applications solves this issue but puts me back at square one.
Any ideas on how we can rectify these issues would be greatly appreciated.
I managed to get around this issue. First, in the content editor, I created a Facebook application under System/Social/Applications. Then, I created a social media account under System/Social/Accounts for LinkedIn and then duplicated it, changing the configuration to suit Facebook.
Once I did this I was able to post text posts to Facebook and Twitter. I was not able to get image posts working, and by this time, we abandoned the idea.
It's worth noting that Sitecore continued to push us toward Komfo. It's pricey and is essentially an iframe placed in the Sitecore UI with limited functionality. There are other tools out there that will give you similar analytics features for a fraction of the price.
It's also worth noting that the social connected functionality in Sitecore 8.1 appears to ask Facebook for the correct permissions, so you wont have this issue. I cannot vouch for its functionality in terms of actually posting as I haven't fully tested it.
Fortunately, Facebook permissions are only string and you can easily modify it using reverse engineering. It was done for Sitecore 7 version, but I think same approach will work for Sitecore 8.
Also, you are able to create a ticket in Sitecore support and they will provide you hotfix for this issue.

Facebook refusing to approve my application - Permission to mention pages

Facebook, a multi billion dollar organisation won't fork out for some live chat agents. Instead I'm stuck in a loop asking for approval, them not reviewing my app properly and giving me a cut/paste response. They say they monitor here, so here's hoping.
Nobody but me will ever use my app. It's a PHP page that posts to our radio station's Facebook page timeline www.facebook.com/BCnowplaying every hour or so, music that's playing on Budgie Collective.
We don't want to spam, this is why the nowplaying page is separate to our normal page.
The app works. All it does is grab a token, store it and post info to the page periodically.
I asked for permission to mention pages. And it was like I divided by zero. I only want this to mention pages of the DJ that compiled the mix that's on air (which is a sanctioned mention, as they have asked for this)... so that when their mix comes on, they are notified.
When I ask for the app to be granted this ability, I get told to show how the public will log in and use the app, and to give sample user accounts. Of course I have explained all this when requesting the permissions. But I keep getting knocked back. Nobody will talk to me directly and every time I re-explain and submit, I have to wait for several days to be given an answer that has nothing to do with how my app works. It's like they aren't even reading the submission.
What can I do next?
Since you're the only one using the application, there is no need to apply for approval. Owners of the application can already use the permission without going through the submission process.
By asking for approval you are basically telling Facebook that you want the public to use the mention feature as well.
So the solution here is to use the app as is and just change the settings to public in Settings > Status
Do you want to make this app and all its live features available to the general public?
Switch to yes.

Facebook custom tab not visible to non-logged in users

Pretty much what the title says.
There are tons of questions about this but the vast majority was only a matter of a missing HTTPS URL, a couple are due to misconfigured app restrictions, and the rest are unsolved.
I have no country or age restrictions in my app, I have both HTTP and an HTTPS URLs, I can see the page when logged in as a page admin and everything works fine, but when visiting the page while logged out, I don't see the tab.
Also, this is not a matter of clicking the tab and not having any content displayed, like in some other questions here. If I'm logged in with my The actual tab link is missing and if I copy the tab URL from when I'm logged in and then try to access it while logged out, I am simply redirected to the page.
I don't think it matters much but this is a tab that has been created via the Graph API. The Graph API docs don't mention anything about tab visibility, at least as far as I see.
This is driving me crazy, I've been at it for hours and can't find any solution or even a hint at what the problem might be.
Any ideas?
EDIT: All I described above is happening with our staging application, which has a self-signed SSL certificate. The live application, which has a "proper" SSL certificate, works just fine. Could the self-signed certificate be the cause of the problem?
Had the same issue this morning. Remove any audience restrictions from your app e.g 13 + or location as this means people have to login to see your app.
So it turns out it was stupidly simple: it was happening on our staging application but not on our live application because our live application uses a non-test FB app, while staging uses a test FB app, which is never seen by people who are not developers (or other staff) on that app.
Talk about wasted time...

What parameters are allowed in Desktop web game policy change?

We have a browser based game which uses Facebook Connect through an AppID that we used to run the same game in a canvas until Fb Credits were introduced and we were forced to shut it down. Now, we only use the App the same way as a product page with the FbConnect integration on our own site.
Today's mail states for our case:
If your Connect app is accessing user connections or asking for additional permissions beyond age, email, and our Publishing Permissions, please remove these requests.
(This refers to this policy change: https://developers.facebook.com/blog/post/2012/09/05/platform-updates--operation-developer-love/)
We are using oauth FbConnect with scope=email,user_birthday. This is exactly what was specified in an earlier mail so it should be ok.
Once the user is authenticated, we simply call
https://graph.facebook.com/me?access_token=...
and read what comes there.
Is it possible, that we are not allowed to call the GraphAPI's me anymore? It contains info like gender, location and locale...
The Oauth data contains the fbuid, first/lastname and the email, but it does not contain the age, what we are supposed to be allowed to ask?
Do I have to call https://graph.facebook.com/me?fields=birthday explicitly?
Did anyone actually succeed in getting an "desktop web game hosted primarily off Facebook" to comply with their new policy without creating a new AppID?
Note: There have been a couple of questions about the "Sep 5th policy change" like Facebook: Notice of Violation this one and many previous closed as duplicates, but none I found so far contains questions or answers on a technical level.
Maybe you could skip the "Website with Facebook Login" part in developer settings and only provide your game directly via canvas. (eg. apps.facebook.com/logogame). that's what "on facebook.com" is all about, I guess.

How do you limit a Facebook app to a small number of people during testing?

I know about test accounts, but during beta I'd like to allow access only to my friends, and then later friends-of-friends, and then only eventually Kevin Bacon and his friends.
That would probably suck, wouldn't it? The app would be listed (is there a way to prevent listing?) and someone I don't know might try it and get a "sorry, this is in development message." I imagine they'd be irritated and not come back.
From what I've read, only a few apps take off, but when they take off, they REALLY take off. Do developers just release these things fully baked?
Anyone start out with OpenSocial or other smaller-than-Facebook networks?
Any ideas for a soft, gradual, restricted roll-out?
Once you've set up your application, there is a setting in the Developer application control panel for your app: Your app -> Advanced -> Sandbox Mode.
Sandbox mode lets you restrict access to only those people listed as developers (under the Basic section).
In terms of expanding the app, Facebook doesn't provide much more flexibility that the Sandbox mode. Unfortunately, adding everyone as Developers of the app doesn't work very well for a beta, as people can access the application control panel once they are a developer. I ended up putting a whitelist of Facebook Ids into the front controller of my application for a previous beta, and it worked fairly well.
The apps are only listed in the App Directory if you submit them and they are accepted. There's no issue about preventing listing, it's something you have to apply for.
As for restricting users, you can accomplish it with a script in the application that checks whether the currently logged-in user is within your restricted user set. For example, if you only want friends of yourself, check whether the current user is friends with your user id. If not, simply display an error/message page or redirect them to the Facebook home page (or wherever). Add this check to the rest of the start-up logic run each page (such as connecting to your DB and authenticating with Facebook).
What I have done in some cases is keep a database table with the user id's of users who are allowed access, essentially a "whitelist". If the user isn't in the table, redirect them.