Sorry, looks like your network settings are preventing access to this feature. 省流:微软疑似封禁了部分 idc 节点,使用其他更好的代理节点或使用请求头插件伪造来源地址
先说解决方法:
X-Forwarded-For
修改为任意非黑名单 ip(如 1.1.1.1)我怎么知道我节点被封禁了? 直接访问或 curl https://www.bing.com/turing/conversation/create
{"result":{"value":"UnauthorizedRequest","message":"Sorry, you need to login first to access this service."}
或任意内容,说明节点未被封禁测试: 使用 oci(已封禁节点) 直接 get 空白 使用 oci 修改来源为 1.1.1.1 成功 使用 oci 修改来源为另一台 oci ip 失败 使用 gcp 直接 get 成功 使用 gcp 修改来源为 1.1.1.1 成功 使用 gcp 修改来源为 oci ip 失败
分析: 做网站的都知道在有前端 cdn 情况下后端是没法知晓访问者的 ip 的,需要 cdn 给源站传递访客信息。
最传统的方式就是让 cdn 修改 header 中的 X-Forwarded-For 为访客 ip ,后端再执行相应逻辑。
但鲜有人知 header 在结构上更接近一个二元数组,而非字典,也就是说一个 header 的 key(比如 X-Forwarded-For)可以对应多个 value(1.0.0.1,1.0.0.2)
而后端若采用字典方式去获取,只能解得第一个(1.0.0.1)。
正常情况下,访客发出的请求 header 中是不会存在X-Forwarded-For
,所以 bing cdn 采取的加入访客 ip 方式应该是 append(添加,而非修改)。但当我们提前加入一个伪造的 ip ,这将成为第一个,而 cdn 添加的真实 ip 则成为第二个,使得欺骗后端防火墙认为自己的来源是第一个 ip 。换句话说,你只要把来源伪造成任意非黑名单 ip 即可。
此漏洞明显,修复方式简单,故修改 header 的可能不会存留很久。 原文出处
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.