Facebook just announced support for multiple app domains (read the post here) in their applications. We're having multiple applications since our website is localized, but now, with
this new feature, we'd like all these applications to be merged into just one.
Is there any way to do this at this current moment?
Alternatively we'd have to ask all of our thousands of users to re-connect with Facebook once again just to get them all on just one single shared application.
There's no way to do this; you could slowly migrate users to the 'new' / 'primary' app - bearing in mind users will have to go through the auth dialog again
Related
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.
I have a multi-tenant web application and I'm wondering which would be the best way to let all the tenant publish their content on the feed of their facebook page (if they have one of course).
There's no public page/link to share so all the shared content has to go straight to the feed (using JS with FB.api feed + photos...). I am wondering which is the most proper way to accomplish this task: having one FB app for every tenant, or using the same FB app for all the different pages, or some other way...
Any suggestions?
I would set this up using a Facebook app for each tenant. This would be forward thinking if you ever want to do further Facebook integration. This also protects your tenants from eachother's behavior. If one tenant violates Facebook policy (There's a lot more of it nowadays) and gets their app locked or anything similar then it won't affect your other tenants ability to interact with Facebook. Also if your application is a white label app then giving each tenant their own Facebook app is almost necessary. Of course each clients having their own app does incur maintenance costs. Whenever Facebook decides to deprecate functionality or implement new features that require their Migration strategies, you'll have to manage each of the apps individually at developers.facebook.com, and depending on how many tenants you have and which features you've integrated with, that can be become tedious since there's no way of automating confirmation of compliance for all of the apps set up. Also now there's a review process for a lot of integration features. That review process would be required for each of the apps individually depending on the features implemented.
Is it possible to limit the total number of user installs of a Facebook application using Facebook API or configuration?
Obviously the beauty of Facebook's platform is the virality. However, the greater the number of installations the more server demands grow etc.
So when building applications for clients with fixed budgets (think marketing activity / capping adverts per day based on spend) - is there a way to restrict the total number of users that Facebook allows to install an application?
Specifically talking here about building Facebook Games.
No, there is no build-in mechanism for that – because usually developers are happy about an ever-growing user base.
A canvas app is not really “installed”, users just connect to it. And this is the only point where you could try to handle this – once a user has connected to your app, you can recognize that (via the signed_request parameter or using the JS SDK) when he visits your app next time. So from a certain point on you could just not ask users for login any more (FB.login, redirecting them to the Auth dialog, …).
Obviously your initial app page will still be called, but any stuff you do afterwards with connected users and their data (if that’s what strains your little server most) you could just stop for users that are not already connected. Big downside of this is of course, if a user removes your app (willingly or by accident), they will find no way to re-connect with your app again.
Maybe you should consider hosting your app on a platform like Heroku – it’s free, and I think they will provide you with enough server power to handle your app growing larger than initially planned/expected.
After watching the F8 keynote my company wants to use the options with the new open graph beta.
The situation:
The company is devided in 2 different sites, a record label and a artist management site.
Both sites have the same artists, but have different publish options.
The artist site publish event dates and locations to the graph API and the record label publishes if somebody listens or buys a track.
All the artist have their own domains too and will need to have all the options of the above sites, but then only for the artist itself.
Explaining the setup as mentioned above, do I need to create a app for each site to add the functionality, even though they are basically all the same?? Is there a way to use 1 app on all domains?
You can use one app which hosts all the metadata pages and then redirects users when they click through the links.
I would denote one of your sites to be canonical and use it primarily. Only redirect if it doesn't have the content.
Another option would be to migrate your sites so they live under subdomains of the root domain. Facebook authentication and open graph supports using a single application across all subdomains of a root domain.
I want to build a mobile application that allows end users to sign up and participate in events (like parties, seminars, conferences etc..). Instead of building a CMS from scratch for an administrator to manage events, is it possible to use Facebook Events as the CMS? Then my mobile application will pull information about these events via the Facebook API.
Any one know if it's better for me to build the CMS from scratch or to use FB events? And what are things I have to consider in making this decision?
Let's say events are authored by users of the system, and if we go the FB CMS method, then users MUST have a Facebook account.
This is certainly possible with the events Facebook api. If you wanted all the events associated with an account you own, you could embed an access token into your application. If you want people to accept your event or host the event under their own account you would need to prompt users for permissions to manage events on their behalf.
It's pretty subjective question whether this is a good idea and it depends on what you are trying to achieve. The biggest upside is that its already built for you and designed to scale and wouldn't require servers, etc. The biggest downside I see is that Facebook changes their API and its not always the most reliable (see the always growing bug list they keep). Also, users may need an account depending on how you decide to implement the functionality.