I am working on a use case suggesting some Facebook user may invite his friends to use a given Facebook app, regardless of whether this user is using the App or not. This implies invoking dialogs from the Facebook JS SDK outside of the App Canvas.
Simply including the script path in the remote page would have been too easy. So my question is, is it programmatically possible to load the JS SDK from an arbitrary domain ?
So my question is, is it programmatically possible to load the JS SDK from an arbitrary domain ?
Of course it is – countless websites use it, outside of Facebook.
You might have to specify the domain in your app settings, though. Otherwise Facebook will not allow features like f.e. login/connecting to the app from really “arbitrary” domains.
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.
In my work we often need to build Facebook apps in the form of Facebook Canvas and Website. These apps are available on Facebook direclty (an iframe) and as mobile versions (outside Facebook, in the browser).
We are working with a code base which mixes Facebook JS SDK (authentication and authorization) with PHP SDK (API calls). I find it rather dirty, and not easy to understand for people freshly working on the projects.
It's inconvinient to make API calls with JS, and making them with PHP forces extending access tokens. Authenticating user with JS SDK involves client-side redirects which are ugly to be honest, as they usually occur moments after the current page starts rendering, and so on...
I googled a lot about separating these two SDKs but did not find a clear answer to my questions:
Is it possible to create Facebook app (Canvas, Website) which bases ONLY on PHP SDK? Check login status, login, permissions, making API calls, etc. Would signed request be enough?
Is JS SDK the only full-proof way to determine user's login status at any time?
This link seems to describe what I'm thinking of, however the docs are rather brief (which seems to be a problem of Facebook documentation in general). Can anyone suggest other sources that might help? Does anyone have experience with builing FB aplications based only on server-side?
Thanks.
EDIT:
The link I posted above covers the case of not using ANY SDK, so no, it's not what I'm looking for.
You can even create an App WITHOUT any SDK - with simple CURL calls, for example. So yeah, it is indeed possible to use the PHP SDK only, but the login process is much better with the JS SDK (no redirection needed) and you can´t auto-refresh a user session like it is possible with FB.getLoginStatus afaik.
In short, i would not recommend it, the JS SDK is the very best way to authorize users and refresh Access Tokens. I would only use the PHP SDK (or simple CURL calls) for stuff that MUST happen on the server, and for stuff that includes using the App Secret, for example.
This is a first time I am trying to make a facebook application/game, and I have couple of questions.
Let's say canvas url is http://mysite/first_app/ and facebook app url is https://apps.facebook.com/first_app
I wonder if visited both url-s should a functionality be the same? I mean does facebook give you more tools and freedom if navigated from https://apps.facebook.com/first_app? Or should both url-s look and do the same thing? Is it possible?
I wonder if visited both urls should a functionality be the same
Of course yes. The difference is just that one is deployed at the facebook's app center and the other at your domain.
Yes, you have more tools available in the canvas ("apps.facebook.com.."), as it will send you the user-id without any user consent. Has the user previously used your app, you will also be able to get their accesstoken and fetch more info about them.
It requires some backend code to decode the signed request parameter, which provides you this stuff.
This example is how php handles signed request:
https://developers.facebook.com/docs/facebook-login/using-login-with-games/
If you're using C#, download the Facebook C# (available through NuGet, the package from Outercurve Foundation) and use this example:
How do I parse a signed request in Facebook C# SDK?
I try to handle the user in Facebook context whenever possible. It adds trust and more tools. Although since the Facebook phone/tablet app (App Store/Google Play) doesn't support Facebook apps at all, I often optimize the app for mobile web use also. I read somewhere that over 50% of daily Facebook visists are done using the phone app, so it might be something to think into your app while developing.
UPDATE:
I can see I have misunderstood part of signed request, as commented by Shadowfax and CBroe. In my app, I use the user id from signed request but of course only when the user has already logged on to the app beforehand. My apologies.
If I create an application on Facebook that populates the canvas / iframe on Facebook, do I have to have anything on the home domain that also works? For example, if I have myapp.com do I need an interface on that page that operates independent of facebook for any reason or can I just use my home domain to serve the php files for the iframe in facebook? Also, is there any reason I can't have a separate set of webpages not in facebook that introduce the app, about, contact us, etc.?
Thanks.
Your app will run from your webserver but doesn't have any requirements for showing anything directly from your website. In other words you could create a directory on your webserver and isolate your app.
I'm not aware of any limitations discussing your app in your website but a quick glance over the FB terms of service might highlight anything specific you're trying to do.
We're trying to develop a widget that uses Facebook APIs and other websites (e.g different domains) could embed. We do not want every website to create it's on Facebook app but we'd like everyone using this widget to be connected to our Facebook app.
The problem is that Facebook seems to authenticate only a specific domain for an app (Canvas URL).
Ideas?
Guy
Update: I just realized that for Facebook server API as long as I set the redirect_uri to a valid URL (as defined by the site url) then everything is OK. So I can let my widget call the login and set the redirect_uri to some page we hold on our server that will communicate with the origin. So far so good. Now the problem that remains is whether there's a way to do it using the Facebook JS sdk rather then having to invent the wheel. From what I see there I could find a way to make the JS SDK not use the window.location.href. Ideas?
you just need to create the app, then from the profile site of your app there is an link to let users add the app to their page. (this is also possible via a special link (see the docs))
but be aware, one page can only include your app once. so if you like your "customers" to have your app multiple times on the same page you have to create multiple apps but point the canvas and tab url to the same script.
The other way would be to add child applications directly for the user, so you can let your customers even set a customized icon. This is hard to code couse you have to use old apis (newer one doesnt support the functions anymore) and there is none to null documentation for it. (I have such an app running, if you want to see some examples drop me a note)