好的,所以我通常会在signed_request 的app_data 字段中提供数据,以了解要加载哪个页面。 POST 时,我在处理完有效负载后直接重定向到选项卡。
因此,有两种方法可以请求一个页面,即实际上是一个 facebook 选项卡:GET 和 POST。
获取
使用 GET 时,应始终使用 facebook URL 请求选项卡。例如:标签的子页面“表单”应该有一个类似的 URL:http://www.facebook.com/pages/xXx/[page_id]?sk=app_[app_id]&app_data=form
在您的服务器端代码中,您可以在解码signed_request 后识别app_data 中的数据(请参阅1 和2)。
在指向表单页面的链接中,您还必须添加 target="parent" 属性。
这样,facebook 会重新加载,并且标签感觉比直接链接子页面时要慢。但是您有标识子页面的 URL,这是我们更喜欢的。
此外,您可以期望每个 GET 请求都有一个signed_request。如果没有,则不会通过 facebook 调用它,您可以显示错误消息,或者按照我的建议,重定向到您的选项卡(子页面)。
发布
POST 永远不会有 signed_request。但通常,在冲浪时,浏览器使用 GET 请求。所以你可以假设,如果你收到一个 POST 请求,它要么来自你自己的表单,要么来自黑客攻击。
在这两种情况下,您都要检查该请求的值是否有效。
如果它们有效,您将它们保存到您的数据库并重定向到“成功”页面。例如。如果您准备参加比赛,您应该显示一个页面,以确保用户他/她已成功参与。
如果数据无效,则将错误消息保存到会话中并重定向回显示它们的表单。
我总是建议您在 POST 请求后重定向,无论您是否在 Facebook 选项卡中。但在 facebook 选项卡中,必须使用 javascript 进行重定向,因为它位于 IFRAME 中,并且您希望重新加载整个页面:
<script type="text/javascript">
parent.location.href = 'http://www.facebook.com/pages/xXx/[page_id]?sk=app_[app_id]&app_data=form';
</script>
Post scriptum 1:对我来说,表单总是使用 POST 请求。
Post scriptum 2:如果您不喜欢每次点击都重新加载整个 facebook“框架”的想法,您可以考虑做一些 AJAX 魔术,其中请求被“调味”有额外的数据让您将它们识别为“您的”。