I have the basic OAuth2 working with Facebook but it appears that I need to setup multiple apps in FaceBook to support. When I add platform, I can add only 1 web site and it has a URL. Seems like I need multiple facebook apps to support different environment.
I can configure it for local host and it works, I can reconfigure it for azure and it works, but I can never get both to work. I did configure multiple re-direct URIs to each environment.
Am I correct that I will need multiple facebook apps (appid and app secret), one for each environment?
Yes, you do need multiple apps for this to work under different domains. Facebook now offers the ability to create an app which is the "test version" of an existing app. You will still end up with different apps/app Ids so you need a way within your application to initialise the FB API with the app ID which is configured for the given environment.
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'm creating a Social Media management webapp. This webapp will be used by our customers on there own sites (read, own domains). The webapp connects to a facebook app that we own, to allow them to manage there pages.
I'm using the "Website" platform for the app. During development I've had the "Site URL" set to my localhost url, and the "App Domains" set to localhost. This has worked fine.
However I now realise that this app will not always be run from localhost. It will be run from many differnt domains. I've read many posts about how its not possible to do this anymore, or at least the max is 5 domains by adding multiple platforms.
So how am I supposed to do this? Will I need to create an app on my profile for each customer/site? Will I have to create an app on each customers facebook account and link its app ID to our webapp?
The solution for this was not so bad.
Since AccessTokens are portable, so you can generate them on a single domain, and then use them to access the API from any page.
To do this, I have setup a single page on my own server (not customers server), whos domain is in my Apps Domains property. This page just has the facebook JS SDK, and some code to handle whether or not to show a login or a logout button. I embed this as an iFrame inside my webapp (that can run from any URL). I use
FB.Event.subscribe('auth.authResponseChange' function {});
to look for status changes, then use the the JS postMessage method to send the result of this to the parent of the iFrame, who then sends it to the server. This AccessToken can then be used anywhere.
I have a Facebook app. This app is a "Website with Facebook Login". However, I need to use it across several URLs. One for development, one for testing, and one for production. My urls looks like this:
Dev - http://localhost:[dynamicPortNumber]
Test - http://mysite.azurewebsites.net
Prod - http://www.mysite.com
Unfortunately, I cannot figure out how to allow multiple URLs to be associated with this app so that I can do end-to-end testing. Can someone please explain to me how to do this?
If you are using multiple top-level domains, the only way to handle this would be to create new App IDs for each instance (dev / test / prod).
However, if you have the freedom, using multiple subdomains in the same top-level domain will get you the result you are looking for. For example:
Dev: dev.mysite.com
Test: test.mysite.com
Prod: www.mysite.com
This will allow you to use the same Facebook App ID across all domains, as long as you use "mysite.com" as the App Domain.
Don't forget to add your site's URL in the "Site URL" box in the "website with facebook login" section!
NOTE: I have, in the past, had to add each individual subdomain in the app domain box in an app for it to function properly, but usually it's because I've made an error somewhere else.
Sadly there is no way to deal with the issue of different URLs for development, testing and production using a single Facebook App ID, you will have to create 3 different App IDs for each of the cases and use them at different places.
You can also check out Getting Started with Your Facebook App on Heroku that does the same.
I like to distribute content from within our Content Management System to several online channels like the website, twitter, linkedin and, last but not least, Facebook. Editors can create items and, eventually after a worfklow process, distriute them amongst the different channels.
Off course the website is no problem (it's still a CMS, isn't it). Twitter integration was rather simple. But now I like to create a connector with Facebook.
The approach is like this.
Create a Facebook app: TheCMSFacebookConnector
Give it permissions to write on a wall, create events, add photo
collections, etc. A customer buys the CMS
Within the CMS Manager there is an action to connect the
TheCMSFacebookConnector app to the customers' (corporate) facebook
account
The OAuth dance is performed and the accesstoken en accesstoken secret are stored
From now we use the REST API to add content to the customer's corporate wall. This is exactly the way i did it for the Twitter integration.
But.........
choosing the right integration type
When I create the Facebook app, the Facebook asks me to tell how the app integrates with Facebook. The integration types that seems to fit the best are Native iOS App or Native Android App. In fact the CMS acts as a Native App as well. Has anyone a clue which App Integration type i have to choose?. And are there other parameters that are important to set in a, maybe, different way?
Choosing the authentication flow
A second question is about the OAuth dance. If we distribute the CMS amongst our customers, they host the CMS Manager environment in their DMZ with their own (mostly) corporate URL or, better, they host the CMS Server within the LAN and the Publication Server in the DMZ (we provide some tools to synchronize those servers)
When I do the OAuth dance, the CMS Manager (which is a webapplication) has is own URL. So in the definition of the app i cannot name an unique value for App Domains. From within the "OAuth dance"" code the redirect URL seems to have a connection with the App Domain and cannot be set in a dynamic way. So is it true that for the "OAuth dance" the only valid method is the client-side authentication flow?
Hope that someone can help me with, especially, the first question. Thanks in advance
E.
So is it true that for the "OAuth dance" the only valid method is the client-side authentication flow?
Not necessarily – you could always have an address from your app domain set as redirect_uri, and have that redirect to the CMS users web address afterwards (via a GET parameter in redirect_uri or something like that).
Is there a way of having multiple URLs in the web url box (http://i.stack.imgur.com/zOpqX.png)
I am testing locally but want to test it on the server too.
No, there isn't - what are you trying to achieve with that?
Facebook uses the mobile web URL to redirect any users who hit your canvas link (http://apps.facebook.com/YOURAPP) on mobile, so having multiple URLS there wouldn't work.
Here is an article from last year regarding multiple domain names.
When testing live and local, I'll normally have a live and a staging application set up and then simply switch my app Id and secret based on the url.