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.
what's the difference between apps.Facebook and Facebook.com/COMPANY_NAME/app_1234567 ?
For example: http://www.facebook.com/AcademyofArtUniversity/app_307555419320340
I'm trying to build a similar contact form page for a client, but I when I create an app, I get apps.facebook.com/APP_NAME rather than the app name at the end. Is there a difference? Are these different types of apps, or is one just an older style name?
Bonus question: Why wouldn't Academy of Art (using the second step from their example above) request User permissions to pull in the Facebook Graph data rather than require users to re-enter it? Is this related to my question above? Is there a best practice around using Permissions vs. New Entry?
apps.facebook.com/[namespace] is the primary url to a Canvas app, while the latter, `www.facebook.com/[pagename]/app_[appid] is your app added to a page as a Page tab app.
For the second question, this app probably doesn't want to ask for permissions (perhaps to lower the friction) since only a few fields would actually be accesible via the graph.
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 am trying to create a sweepstakes application.
I am trying to copy wildfire.
But I am unable to create facebook applications dynamically like they are doing.
I checked it they are using graph api to show on front end but there is no method available in graph api to create applications dynamically.
Can anyone please guide me how wildfire is doing dynamic app creation. Is there any alternative available?
In general, they are likely not creating new applications for each client. Unless you can show us evidence of this, it is the same application being installed many times onto their client's Facebook Pages.
The application script can detect the Page ID and change the display logic appropriately. Seen here:
Get Facebook fan page ID
If you really want to create applications for your clients, take a look at this thread:
http://facebook.stackoverflow.com/questions/6264080/create-a-facebook-application-programmatically
EDIT (Not being able to comment is horrible) in response to J's post:
There is not a way to create applications entirely programmatically, but you can get really close creating a user-flow around:
https://www.facebook.com/connect/create_app.php?api_key=[key]&name=app_name
Where [key] is the api_key of the parent application. It isn't documented anywhere so you should have a manual fall back in place. The link above does work to create a new Facebook application tied to the currently logged in user (the parent api_key does not seem to have any effect but it is required).
To determine the api_key of the application created, ask the user for the appropriate permission and query /accounts to retrieve a list of Facebook applications the user owns. Do this before and after the user clicks the above link to determine which one was just created. From there, have the user get a new access_token and get the appropriate permissions to modify application settings. You should then customize the newly created application.
Mike
This has been mentioned several times in the old Facebook forum.
Wildfire, North Social et al, do not create applications dynamically. It's the same application being installed by many clients.
How is this possible? Well, when a Page loads a tab application, Facebook pass you a signed_request parameter. When you decode this signed request with your application's id and secret, you will find inside the page id from where the tab application is being called. You can then use this to work out which of your clients is making the call to your code and therefore what content to deliver to the browser.
There have been changes to the Graph API recently to allow you to manage applications once created but you cannot (and likely will never be able to) create applications programmatically through the Graph API.
The second thread mentioned by Mike mentions child applications but this was deprecated from the Facebook code base some time ago and would not actually allow the creation of applications in the way I assume you want.
J
Background:
I am working on a legacy ASP.NET 3.5 Web Forms applications. The application allows users to buy a subscription to a 'white-label' website which is generated for them and they can customize it further. It uses forms authentication.
A typical use-case is that the user creates an account on our system, purchases a website, and then proceeds to customize their website. The URL they will use to edit their purchased website is something like this: https://www.example.com/EditWebsite.aspx. There are many other pages also within our website editing toolbox with other URLs.
Problem:
My team has now been tasked with allowing people to use one account to access multiple website subscriptions. This means that one authenticated user could be trying to access one of many websites to edit if they use the URL mentioned above. Our system can be made aware of multiple subscriptionIds per User but the website editor web app only has support for one subscription.
To clarify with a simpler example: this would be like if Google all of a sudden allowed you to view two different inboxes with one GMail account. How would the system know which one you were trying to access if the URLs were the same for both?
We originally wanted to change the application to use URLs like: https://www.example.com/[subID]/EditWebsite.aspx which would give us all the information we need to send the user to the correct website. We looked into URL Routing to accomplish this but it seems that we would have to change all of the web app's internal links to use the route config to generate the correct URLs. Maybe we have the wrong idea here but it seems like too much work for a legacy application.
Another potential solution we came up with was simply using our systems' control panel web app (where they click links to edit any of their websites) to set a session cookie which our edit website web app can read to know which website to bring up. This has the disadvantage that the pages would not be bookmark-able and you could not look at multiple websites at once in different tabs of the same browser.
Question(s):
Is there any other options we have not investigated or thought of? Is there any other web sites which allow for this kind of behavior; how do they handle it? Is URL Routing the right way to do this and we just need to take the plunge?
Any input is appreciated!
The solution we ended up using was adding a URL parameter to the link which specifies which website you are trying to edit.
https://www.example.com/EditWebsite.aspx?subID=123
This parameter is included in the links to 'Edit Website' from the page which lists all of a user's websites.
When present, this sets a session cookie for the user. If the request parameter is not present, the app looks for the cookie being set; this handles all the internal links within the application. if a cookie doesn't exist and the request parameter was not set, we just pick the authenticated user's first subscription from the list.
This isn't perfect but it has worked without issue so far. The only consequence it has caused is that a user cannot edit multiple websites in the same browser session, e.g. using multiple tabs. This hasn't resulted in any support issues yet though so it is pretty much a non-issue.