从中间层发布到 Facebook 页面 (PHP)

发布于 2024-11-07 19:36:39 字数 459 浏览 0 评论 0原文

我正在尝试构建一个原型,允许公司远程管理多个 Facebook 企业页面。

想象一下以下数据流(对于一个页面):

  1. 模块 1 在 cron 作业上运行并从页面检索帖子/评论。
  2. 后端应用程序列出帖子和用户回复
  3. 回复和帖子从模块 2 发回 Facebook

我的问题是: 每个模块(包括模块 2)都位于公司防火墙后面,并且应该能够发布到公司的 Facebook 页面,而无需注册 Facebook 应用程序或以通常的方式进行身份验证。为什么?首先,使用当前的 Facebook oAuth 方法,您必须包含重定向 URL。除了我的 Intranet 之外,我不想被重定向到任何其他地方。由于 Facebook 无法“看到”我的内联网,因此不会生成 auth_token。

总之,如何使用该页面的管理员用户 FBUID 发布到 Facebook 企业页面以获得 auth_token?

I'm trying to put together a prototype that would allow a company to manage remotely several Facebook Corporate Pages.

Imagine the following dataflow (for one Page):

  1. module 1 runs on a cron job and retrieves posts/comments from a Page.
  2. backend app lists posts and users reply
  3. replies and posts are posted back to Facebook from module 2

My question is:
Every module (including module 2) is behind company firewall and should be able to post to company's Facebook Page without having to register a Facebook App or being authenticated the usual way. Why? First of all, using current Facebook oAuth approach you have to include a redirect URL. I do not want to be redirected to anywhere else than to my intranet. Since Facebook does not "see" my intranet, the auth_token is not generated.

In conclusion, how to post to Facebook Corporate Page using that Page's admin user FBUID only to get auth_token?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

愛上了 2024-11-14 19:36:39

您必须至少对您的应用程序(并且您确实需要一个应用程序)进行一次身份验证。您当然可以请求offline_access,这样您就不会需要有一个活动的用户会话(如果你想成功运行你的 cron 作业,你就需要这样做),但即使启用了 offline_access 的令牌在一段时间后也会变坏(当用户更改时)他们的密码,或卸载/重新安装)。

我建议将您的 cron 服务器放在防火墙前面,并让用户在幕后管理其余部分,让他们使用一个身份验证令牌。您可以通过 /me/accounts 获取正确的令牌,并且您需要请求 manage_pagesoffline_access。获得身份验证令牌后,只需将其存储起来直至其过期(希望不会持续很长时间)。

You're going to have to authenticate your app (and you do need an app) at least once. You can certainly ask for offline_access so you don't need to have an active user session (and you'll need to, if you want to run your cron job successfully), but even offline_access-enabled tokens do go bad after a while (when a user changes their password, or uninstalls/reinstalls).

I'd recommend putting your cron server in front of the firewall and let users manage the rest behind the scenes, letting them use one auth token. You can obtain the proper token through /me/accounts, and you'll want to ask for manage_pages and offline_access. Once you get your auth token, simply store it until it expires (hopefully not for a really long time).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文