如何在不同网站使用同一个 Facebook 应用程序
我正在用 PHP 开发一个小型 CMS，我们正在进行社交集成。
内容由有权发布新闻、事件等的单个管理员更改...
我想添加此功能，当管理员发布已经发布在 Facebook 墙上的内容时。我对 facebook php SDK 不太熟悉，对此我有点困惑。
如果（举个例子）10 个不同的网站正在使用我的 CMS，我是否必须创建 10 个不同的 Facebook 应用程序？ （假设这 10 个网站都在不同的域和服务器中）
第二，有没有一种方法可以仅使用 PHP 进行身份验证（例如直接发送用户名和密码），以便用户不需要登录 facebook？
谢谢
I'm developing a small CMS in PHP and we're putting on social integration.
The content is changed by a single administrator who as right for publishing news, events and so on...
I'd to add this feature, when the admin publishes something it's already posted on facebook wall. I'm not very familiar with facebook php SDK, and i'm a little bit confused about it.
If (make it an example) 10 different sites are using my CMS, do I have to create 10 different facebook application? (let's assume the 10 websites are all in different domains and servers)
2nd, is there a way for authenticating with just PHP (something like sending username&password directly) so that the user does not need to be logged on facebook?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能想将问题分解为更小的可理解的单元。很难理解你的驾驶意图。
我对你的问题的理解可能很少，但这里是...
1_ 不，你不会创建 10 个不同的 Facebook 应用程序。创建一个 Facebook 应用程序并将其作为服务入口点。这样您的所有 cms 站点都可以与该站点对话以与 facebook 进行交互。 （REST 服务层）。
2_ Facebook api不支持用户名和密码验证。他们只支持oauth2.0。尽管 Oauth 并不简单，但由于他们为此提供了库，因此实现身份验证非常简单。
You might want to break up your question in to smaller understandable units. Its very difficult to understand what you are driving at.
My understanding of your problem could be minimal, but here goes...
1_ No you do not create 10 different facebook application. Create a single facebook application and make it a service entry point. So that all your cms sites could talk to this one site to interact with facebook. ( A REST service layer).
2_ Facebook api does not support username and password authentication. They only support oauth2.0. Although Oauth is not trivial, but since they have provided library for that, implementing authentication is pretty trivial.
请阅读 http://developers.facebook.com/docs/。
它真的很简单、直接并且解释得很好。
你的问题如此模糊和广泛，在这里无法得到很好的回答。
如果您遇到任何具体的实施问题，这里就是正确的地方。
不过，至少要回答您问题的一部分：
使用 facebook 应用程序时最强大的工具是 Graph API。
它的原理非常简单。您几乎可以代表任何用户或应用程序执行任何操作。您必须首先生成一个令牌来标识用户和适当的权限。这些令牌可以设置为“永久”，以便您可以执行后台任务。通常它们只活跃很短的时间，因此您可以在与用户交互时执行操作。生成令牌的过程涉及用户，因此他/她必须确认您所要求的权限。
对于自动发布内容的网站，您可能会生成一个永久令牌，只要您在隐私设置中删除该应用程序，该令牌就会处于活动状态。
基本上你可以使用任何网站上的任何应用程序。没有限制。然而，有两种生成令牌的方法。一种涉及额外的请求，另一种是在客户端完成的，该请求绑定到您的应用程序设置中指定的一个域。
附录：
@ArtoAle，
您对每个应用程序都分配给一个域的说法是正确的。然而，一旦您获得了有效的令牌，您在图形 API 中从何处或由谁使用它并不重要。
让我解释一下：
这没有任何意义，因为是您在执行请求。不存在“请求来自哪里”这样的事情。当然，还有“referer”标头信息，但它可以自由指定，并且不会在任何上下文中使用。
您在应用程序设置中输入的域仅限制 Facebook 将用户重定向到的位置。
为什么？
这确保了一些坏人无法在任何域上设置网站并让用户授权应用程序并使用您的应用程序获取访问令牌。
因此，此设置可确保用户和访问令牌重定向回您的站点，而不是另一个不良站点。
但还有一个替代方案。如果您使用桌面应用程序的控制流，则在用户重定向回来后您不会立即获得访问令牌。你会得到一个临时的会话令牌，你可以用它交换访问令牌。此交换是通过 REST api 在服务器端完成的，并且需要您的应用程序密钥。所以此时可以确保是您获得了代币。
此方法可以在任何域上执行，或者如果桌面应用程序根本不在域上执行。
这是来自faceboo文档的引用：
但是您不需要此方法，因为它有点复杂。对于您的用例，我建议使用授权中心点。
因此，您可以指定您的 ONE 域作为重定向 URL。该域名在您的网站之间共享。在那里，您可以获得完全有效的访问令牌，并将用户无缝重定向回您的特定项目网站并传递访问令牌。
这样您就可以使用传统的简单身份验证流程，这可能也更适合未来。
事实依然如此。生成访问令牌后，您可以从任何域执行任何操作，没有区别，因为请求来自的实际上没有“域”（见上文）。
除此之外，如果您想要一些不错的 javascript 功能 - 例如评论框或点赞按钮，您需要设置 正确打开图表标签。
如果您遇到一些实施问题或如您所说的“域错误”，请更清楚地描述它们，包括您所做的步骤，如果可能的话，包括错误消息。
Please read up on http://developers.facebook.com/docs/.
Its really easy and straight forward and well explained.
Your question is so vague and extensive that it cannot be answered well here.
If you experience any specific implementation problems, this is the right place.
However to answer atleast a part of your question:
The most powerful tool when working with facebook applications is the Graph API.
Its principle is very simple. You can do almonst any action on behalf of any user or application. You have to generate a token first that identifies the user and the proper permissions. Those tokens can be made "permanent" so you can do background tasks. Usually they are only active a very short time so you can perform actions while interacting with the user. The process of generating tokens involves the user so that he/she has to confirm the privileges you are asking for.
For websites that publish something automatically you would probably generate a permanent token one time that is active as long as you remove the app in your privacy settings.
Basically yuo can work with any application on any website. There is no limitation. However there are two ways of generating tokens. One involves on an additional request and one is done client side, which is bound to one domain oyu specifiedin your apps settings.
Addendum:
@ArtoAle
you are right about every app beeing assighend to exactly one domain. however once you obtained a valid token it doesnt matter from where or who you use it within the graph api.
let me expalin this a little bit:
it would make no sense since it is you doing the request. there is no such thing as "where the request is coming from". of course there is the "referer" header information, but it can be freely specified and is not used in any context of this.
the domain you enter in your apps settings only restricts where facebook redirects the user to.
why?
this ensures that some bad guy cannot set up a website on any domain and let the user authorize an app and get an access token with YOUR application.
so this setting ensures that the user and the access token are redirected back to YOUR site and not to another bad site.
but there is an alternative. if you use the control flow for desktop applications you don't get an access token right after the user has been redirected back. you get a temporary SESSION-TOKEN that you can EXCCHANGE for an access token. this exchange is done server side over the REST api and requires your application secret. So at this point it is ensured that it is YOU who gets the token.
This method can be done on any domain or in case of desktop applications on no domain at all.
This is a quote from the faceboo docs:
However you don't need this method as its a bit more complex. For your use case i would suggest using a central point of authorization.
So you would specify your ONE domain as a redirect url. This domain is than SHARED between your websites. there you can obtain the fully valid access token and seamlessly redirect the user back to your specific project website and pass along the access token.
This way you can use the traditional easy authentication flow that is probably also more future proof.
The fact remains. Once the access token is generated you can perform any action from any domain, there is no difference as ther is literally no "domain" where the request is coming from (see above).
apart from that, if you want some nice javascript features to work - like the comments box or like button, you need to setup up open graph tags correctly.
if you have some implementation problems or as you said "domain errors" please describe them more clearly, include the steps you made and if possible an error message.