无需 appid 即可为我的客户提供 Facebook 连接服务 [英] Facebook connect service for my customers without appid

问题描述

我有不少客户想要将 facebook 连接添加到他们的登录页面(由我管理).他们太多了，而且技术含量不够，无法为每个人手动创建广告 appid.所以我唯一的解决方案是使用我自己的 appid 将 facebook 连接添加到我所有的客户网站，但据我所知，Facebook 不允许在任何域上简单地使用相同的 appid.我该如何解决这个问题?我找不到任何文档来解决我的问题.有人给我指路吗?

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?

推荐答案

这之前已经讨论过几次了——但我主要评论了之前的问题，所以让我把整个事情写成一个正确答案，以供将来参考.

[释义] 通过一个应用 ID 登录多个客户端的 Facebook

[paraphrased] Multiple-client Facebook login via one single app id

有人给我指路吗?

在多个不同的域中运行一个简单的应用程序实际上是不可能的.

It is not really possible to run one simple app one multiple different domains.

作为仅适用于少数域的解决方法，人们过去常常为不同平台(网站、页面选项卡或 Canvas 应用程序，以及 Canvas 的移动替代方案)指定不同的域，实际上除了网站之外没有使用任何这些平台，这使得应用程序可在多个域上用作网站应用程序.但由于 Facebook 引入了他们的登录/权限审查流程¹，您不能再这样做了 - 他们希望您在您在应用中配置的所有平台上展示实际功能.

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.

但这有几个缺点:

• 这不是您所说的白标"解决方案.如果您的客户希望它看起来像是用户通过他们的"应用登录，那么它应该留在他们的域中.在登录对话框中显示的应用程序名称、应用程序徽标等方面的个人品牌化也是不可能的.此外，应用属性(显示在通过应用共享/发布的内容下的链接)只会将用户链接回主域，而不是您客户的域.

• 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.

您将无法将 JS SDK 用于客户端 API 请求，甚至无法将其嵌入以呈现任何需要应用程序 ID 的 FB 社交插件——SDK 会检查它是哪个域正在运行"，并且不能被欺骗接受未在应用设置中指定的域.

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.

可能存在隐私问题.一个过于夸张的例子:仅仅因为我作为应用程序用户决定与您的客户分享我在 Facebook 上的照片或视频 Our-Holy-Mother-of-Christ-Bakery.com，并没有必然意味着我想与您的其他客户共享它们，amateurs-doing-all-kinds-of-nasty-stuff.xxx 以及 - 但如果他们出于登录目的共享应用程序 ID，我会自动会.为那个场景写下隐私政策(如果您使用 FB 登录功能，这是强制性的，FB 还会自动检查您的应用是否有)，祝您玩得开心;-)

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 ;-)

最后，也是最重要的一点:您的所有客户都将坐在同一条船上".如果他们中的一个人，或者反过来他们的网站用户，会通过您的应用程序 ID 发布垃圾邮件，以便 Facebook 阻止它，登录将不再适用于您客户的所有网站.如果你只决定然后，为你的每个客户设置一个单独的应用程序将是更好的方法，他们将无法再识别他们现有的用户，因为用户 ID应用范围自从引入 API v2.0 以来 - 所以如果用户登录这个新应用，该应用将看到一个完全不同的用户 ID.(依赖电子邮件地址作为标识符也是有风险的，因为您不会从 API 中为每个用户获取一个；例如，如果他们使用移动设备进行注册.)

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.)

另外，应用/域洞察，正如 luschn 在他的回答中提到的那样.

Plus, app/domain insights, as luschn mentioned in his answer.

¹ 是的，审核过程让为多个客户设置多个应用变得更加费力.但是对于以相同方式执行相同操作/使用相同权限的应用程序，您可以参考之前成功审核的应用程序 ID 以稍微加快进程.此外，截图如何 f.e.通过该应用发布的帖子在时间轴上的外观、使用的 UI 组件以及您在提交中包含的截屏视频可能几乎不需要改动就可以使用.

¹ 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.

这篇关于无需 appid 即可为我的客户提供 Facebook 连接服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！