Facebook回调已经开始追加#_=_哈希下划线返回URL

有人知道为什么吗?解决方案是什么?


当前回答

如果你使用的是带有hashbang (/#!/) url的JS框架,比如Angular,这可能会成为一个严重的问题。实际上,Angular会认为带有非hashbang片段的url是无效的,并抛出一个错误:

Error: Invalid url "http://example.com/#_=_", missing hash prefix "#!".

如果你在这种情况下(重定向到你的域根目录),不要这样做:

window.location.hash = ''; // goes to /#, which is no better

简单地做:

window.location.hash = '!'; // goes to /#!, which allows Angular to take care of the rest

其他回答

不知道他们为什么这样做,但是,你可以通过重置页面顶部的哈希来解决这个问题:

if (window.location.hash == "#_=_")
  window.location.hash = "";

如果你使用的是带有hashbang (/#!/) url的JS框架,比如Angular,这可能会成为一个严重的问题。实际上,Angular会认为带有非hashbang片段的url是无效的,并抛出一个错误:

Error: Invalid url "http://example.com/#_=_", missing hash prefix "#!".

如果你在这种情况下(重定向到你的域根目录),不要这样做:

window.location.hash = ''; // goes to /#, which is no better

简单地做:

window.location.hash = '!'; // goes to /#!, which allows Angular to take care of the rest

删除“#_=_”(PHP)的最简单和干净的解决方案:

用“echo(”Location .php)代替“header("Location: xxx.php");"Href = 'xxx.php';");"

一个对我有用的解决方法(使用Backbone.js)是在传递给Facebook的重定向URL的末尾添加“#/”。Facebook将保留提供的片段,而不会附加自己的“_=_”。

返回时,Backbone将删除“#/”部分。对于AngularJS,在返回URL后附加“#!”应该可以工作。

注意,大多数浏览器在重定向(通过HTTP状态码300、301、302和303)时保留原始URL的片段标识符,除非重定向URL也有片段标识符。这似乎是被推荐的行为。

如果使用处理程序脚本将用户重定向到其他地方,则可以在此处的重定向URL后附加“#”,以将片段标识符替换为空字符串。

将此添加到我的重定向页面解决了我的问题…

if (window.location.href.indexOf('#_=_') > 0) {
    window.location = window.location.href.replace(/#.*/, '');
}