I have more than few clients that would like to add facebook connect to their landing pages (managed by me). They are too many and not enough tech-savvy to manually create ad appid for each of them.
So my only solution is to usa my own appid to add facebook connect to all my clients websites, but as far as I know, Facebook doesn't allow to simply use the same appid on any domain.
How can I solve this? I can't find any documentation to solve my issue. Does anyone have a direction for me?
This has been discussed a couple o’ times before already – but I mostly commented on earlier questions, so let me write the whole thing up as a proper answer, for future reference.
[paraphrased] Multiple-client Facebook login via one single app id
Does anyone have a direction for me?
You probably rather don’t want to do that.
It is not really possible to run one simple app one multiple different domains.
As a workaround for only a few domains, people used to specify different domains for the different platforms – Website, Page Tab or Canvas App, plus Mobile alternative for Canvas – without actually using any of those platforms besides Website, which made the app usable on multiple domains as a website app. But since Facebook introduced their login/permission review process¹, you can’t do that any more – they expect you to present actual functionality on all platforms you have configured in your app.
You can kind-off use one single app for login on multiple domains – if you are willing to use only the server-side login flow, and to redirect users to one “main” domain (that gets specified as the app domain in the app settings) to login, and then from there back to the origin domain.
But this has several drawbacks:
It’s not what you’d call a “white label” solution. If your clients expect it to look as if users where logging in via “their” app, it should stay on their domain. Individual branding, in regard to stuff such as app name, app logo that shows in the login dialog, etc., would also not be possible. Additionally, app attribution – the link that shows up under content shared/posted via the app – would only link users back to the main domain, and not to your customer’s.
You would not be able to use the JS SDK for client-side API requests, or even just to embed it to render any of the FB social plugins that require an app id – the SDK checks what domain it is “running on”, and can not be tricked to accept a domain that is not specified in the app settings.
There could be privacy issues. An over-exaggerated example: Just because I as the app user decided to share my photos or videos I have on Facebook with your customer Our-Holy-Mother-of-Christ-Bakery.com, does not necessarily mean I want to share them with your other customer, amateurs-doing-all-kinds-of-nasty-stuff.xxx as well – but if they shared an app id for login purposes, I automatically would. Have fun writin’ the Privacy Policy (which is mandatory if you use FB login functionality, and FB also automatically checks if your app has got one) for that scenario ;-)
Finally, and most importantly: All your customers would be “sitting in the same boat.” If one of them, or in turn their website users, would publish spam via your app id, so that Facebook blocks it, login would not work any more for all of your customer’s websites. And if you decide only then, that setting up an individual app for each of your customers would be the better way to go, they would not be able to recognize their existing users any more, because of user ids being app-scoped since API v2.0 was introduced – so if users logged into this new app, that app would see a totally different user id. (And to rely on an email address as an identifier is risky, too, because you will not get one from the API for every user; for example if they registered using their mobile device.)
Edit: Plus, app/domain insights, as luschn mentioned in his answer.
¹ Yes, the review process has made it more laborious to set up multiple apps for multiple clients. But for apps that do the same stuff/use the same permissions in the same manner, you can refer to an earlier successfully reviewed app id to speed up the process a little. Also, screenshots of how f.e. posts made via the app look on timeline, and what UI components are used, as well as screencasts that you include in your submission could probably be used with little to no alteration.
Apps are not meant be used on several different domains, you will have to create a new App for each domain, i´m afraid. You can use the different platforms in the App settings to use different domains, but there are only a few so it´s pointless. Just create some screenshots and a tutorial for your clients, that´s how it is usually done.
Btw, it would be weird to authorize an App on a website, and the same App would allow you to be authorized on all other client websites. Also, insights are per App, so your clients may want to see their own insights and not the global insights of all domains together.
Many is not defined but i think for being a smart developer you need to create new app_ids for every project you need to use facebook connect. Just my opinion. It also allows you to monitor alot of stuff.
Related
I've got incoming messages working via webhook, but what I cannot understand is how I make this available to other users.
I run a SaaS that's used by many different organisations, so I want to be able to give those organisations (who each have a subdomain on my domain) the ability to 'connect to facebook messenger', so that all of the messages to their facebook page (whatever that may be), come into their portal view on my platform.
The only way I can see this working, is by getting each user to register as a developer, and go through all the set up that I did to get my test example working.
But I must be missing something? What's the workflow to enable this, simply, so that users can connect in this way?
You can have multiple Facebook pages connected to your single Facebook app. But you would require permissions from Facebook for that. You can read about permissions here: https://developers.facebook.com/docs/facebook-login/permissions/
I have like/share buttons on my website and am not currently using an appid. Finding information on whether this is a necessity for the above configuration is difficult to confirm. When going through the Facebook app "create" forms, I'm really confused by a lot of the requirements as it seems to be more focused around actual apps rather than websites, which login via fb etc.
In the past I have created an app for one of my other websites and I don't believe there was any verification/submission process at this point (about 2-3 years ago). Reviewing my old app configuration now I can see that it is not "live" - does anyone know whether Facebook implemented this submission process in the last couple of years, and then de-activated any live apps that were created prior to this?
I now want to setup a new app for my new website and I'm unsure what the different 'action types' mean and what I would need to simply use like/share buttons on the website. Could someone give me a quick run down of what I'd need and what they are?
Any other info/tips people can provide would be greatly appreciated. I'm finding that the like/share DO still work without the app, but sometimes the share button doesn't work properly (I have a feeling this is something to do with the app).
Thanks
If you are just using the Social Plugins, you don't need to have a Facebook App ID.
If you want more integration, it will be required. Creating an App ID is like registering your App, wether an iOS or Android App or just a website, so that you can make Graph API calls for it.
The easiest way to register your website is to go the quickstart: https://developers.facebook.com/quickstarts/?platform=web (or https://developers.facebook.com/apps). There you can type a name and follow the steps.
You can then follow the "Sharing best practices" (https://developers.facebook.com/docs/sharing/best-practices#tags) on how to use the App ID. For example, by including an fb:app_id meta tag on your pages.
There is a review process, since last April, but that is only needed if you use permissions for your App. If you just use the plugins, that is not needed.
Can you explain more what is exactly not working?
Update
The time you create a page the Facebook crawler does not know yet what the Opengraph data for that one is. This will happen after the first share, but if you want to ensure it is correct from the first share on, you can force a re-scrape.
This section explains how that works:
https://developers.facebook.com/docs/sharing/opengraph/using-objects#update
When an app triggers a scrape using an API endpoint This Graph API
endpoint is simply a call to:
POST /?id={object-instance-id or object-url}&scrape=true
I freelance now and I am wanting to set up a Facebook account so I can create multiple apps for different clients under this account, then become admin and roll out the app totheir page.
Does anyone else do this and if so how best is it to set up from the outset as I will need to test without the public seeing etc.
Yes - I do this frequently...
Placing your application in sandbox_mode will ensure that only the people who are allowed to see the application have access to it.
You can also add your applications to your own un-published Facebook page, that way no one will be able to search for your page or application either.
A mixture of sandbox_mode and an un-published page should be the safe way to go. Check out the Application Security page in Facebook's documentation for exact explanations of sandbox_mode and the roles you can give users in your application.
I have a question about increasing visibility of Facebook app notifications.
As far as I can tell, there are only 2 places where Facebook app requests appear for users who don't click the "Apps & Games" section - in the top right section (https://skitch.com/nicksoman/8172w/facebook) or in the jewel (https://skitch.com/nicksoman/81737/2-facebook) - I believe the wording is a bit different on this one if recipients haven't used the app, as it references an invite rather than a request.
As other have noted, neither of these channels provides any context around the request. In the past I've seen context for apps like BranchOut and FarmVille, but I can't replicate this behavior by sending invites from these apps now (can anyone)?
Has anyone found a Facebook-approved way to either provide more context around these app requests or make them more visible?
I'm familiar with the history of Facebook tweaking channels due to abusive apps - just want to make sure I'm current on best practices today.
Are you referring to users who haven't authorized your app or users who did?
Basically, facebook calls this Social Channels and you have a few options, again, depending on if the user is already using your app or not.
If the user is using your app, you have the bookmarks bar which can be used by issuing a App-generated requests.
If the user isn't using your app then a friend of his that is using your app can send him a User-generated request.
You can and should encourage your users to publish your app stories to their friends' feed and/or to send them to friends.
There's that "Automatic Channels" which is discussed in the first link in this answer.
More options are to use the Social Plugins in your website, and to have a mobile version of your app.
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.