奇怪的网址后附有“#_ = _" [英] Weird url appended "#_=_"

查看:75
本文介绍了奇怪的网址后附有“#_ = _"的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

可能重复:
附加# = 的播放框架要通过OAuth2在Facebook身份验证后重定向?

Possible Duplicate:
Play Framework appending #= to redirect after Facebook auth via OAuth2?

还有其他人看到过这种情况吗?

Has anyone else seen this happen?

我正在使用Facebook PHP SDK和一些Javascript构建Facebook canvas应用.
现在,当我通过OAuth身份验证流程引导用户时,我注意到浏览器中的URL会自动附加此"#_=_",因此我的URL开始看起来像这样:

I am building a Facebook canvas app using the Facebook PHP SDK, and some Javascript.
Now when I take the user through the OAuth authentication flow, I have noticed that the URL in the browser automatically gets appended with this "#_=_" , so my URL starts looking like this:

http://apps.facebook.com/xxxxxxxxxxxx/#_=_

,当我重定向到应用程序配置文件页面时,URL为:

and when I redirect to the app profile page the URL is this:

http://www.facebook.com/apps/application.php?id=xxxxxxxxxxxx#_=_

我正在使用重定向

echo "<script type='text/javascript'>top.location.href='$appcanvasurl';</script>"

到画布URL,然后

echo "<script type='text/javascript'>top.location.href='$appprofurl';</script>"

用于应用程序配置文件页面.

for app profile page.

那么为什么这个#_=_会被追加?

So why is this #_=_ getting appended?

更新:

根据

According to this bug on the tracker, this is by design, and giving a value for the redirect_uri does not change this.

并且根据

And according to the official facebook reply on that page (have to be logged in to Facebook to view the post):

此标记为设计使然",因为它可以防止潜在的安全漏洞.

This has been marked as 'by design' because it prevents a potential security vulnerability.

某些浏览器会将哈希片段从URL附加到已重定向到的新URL的末尾(如果该新URL本身没有哈希片段).

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).

例如,如果exam​​ple1.com返回重定向至example2.com,则浏览器将转到example1.com#abc,而浏览器将转到example2.com#abc,并且example1.com的哈希片段内容将可供访问example2.com上的脚本.

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.

通过在重定向URL上添加新的哈希片段以防止这种浏览器行为,可以缓解这种情况.

This is mitigated by appending a new hash fragment to the redirect URL to prevent this browser behavior.

如果要关注所生成URL的美观性或客户端行为,则可以使用window.location.hash(甚至是您自己的服务器端重定向)来删除有问题的字符.

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/blog/post/552/

会话重定向行为的更改

这周,我们开始将片段#_=_添加到redirect_uri 当此字段保留为空白时.请确保您的应用程序可以处理 这种行为.

Change in Session Redirect Behavior

This week, we started adding a fragment #_=_ to the redirect_uri when this field is left blank. Please ensure that your app can handle this behavior.

这篇关于奇怪的网址后附有“#_ = _"的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆