Facebook回调已经开始追加#_=_哈希下划线返回URL
有人知道为什么吗?解决方案是什么?
Facebook回调已经开始追加#_=_哈希下划线返回URL
有人知道为什么吗?解决方案是什么?
当前回答
一个对我有用的解决方法(使用Backbone.js)是在传递给Facebook的重定向URL的末尾添加“#/”。Facebook将保留提供的片段,而不会附加自己的“_=_”。
返回时,Backbone将删除“#/”部分。对于AngularJS,在返回URL后附加“#!”应该可以工作。
注意,大多数浏览器在重定向(通过HTTP状态码300、301、302和303)时保留原始URL的片段标识符,除非重定向URL也有片段标识符。这似乎是被推荐的行为。
如果使用处理程序脚本将用户重定向到其他地方,则可以在此处的重定向URL后附加“#”,以将片段标识符替换为空字符串。
其他回答
适用于PHP SDK用户
我只是通过在转发之前删除额外的部分来解决这个问题。
$loginURL = $helper->getLoginUrl($redirectURL, $fbPermissions);
$loginURL = str_replace("#_=_", "", $loginURL);
header("Location: " . $loginURL);
Facebook最近在处理会话重定向的方式上做出了改变。有关公告,请参阅本周Operation Developer Love博客文章中的“会话重定向行为的更改”。
你也可以在Facebook回调的redirect_uri参数上指定你自己的散列,这在某些情况下可能是有帮助的,例如/api/account/callback#home。当你被重定向回来,它至少是一个哈希,对应于一个已知的路由,如果你使用backbone.js或类似的(不确定jquery移动)。
将此添加到我的重定向页面解决了我的问题…
if (window.location.href.indexOf('#_=_') > 0) {
window.location = window.location.href.replace(/#.*/, '');
}
这是Facebook出于安全考虑而设计的。下面是Facebook团队成员埃里克·奥斯古德的解释:
This has been marked as 'by design' because it prevents a potential security vulnerability. Some browsers will append the hash fragment from a URL to the end of a new URL to which they have been redirected (if that new URL does not itself have a hash fragment). For example if example1.com returns a redirect to example2.com, then a browser going to example1.com#abc will go to example2.com#abc, and the hash fragment content from example1.com would be accessible to a script on example2.com. Since it is possible to have one auth flow redirect to another, it would be possible to have sensitive auth data from one app accessible to another. This is mitigated by appending a new hash fragment to the redirect URL to prevent this browser behavior. If the aesthetics, or client-side behavior, of the resulting URL are of concern, it would be possible to use window.location.hash (or even a server-side redirect of your own) to remove the offending characters.
来源:https://developers.facebook.com/bugs/318390728250352/