由于高版本的chrome对于url方式调用本地程序的弹框关不掉,我一直是通过本地客户端进行浏览器和本地程序通信,具体方式是:
- 本地建一个web服务器,
- Chrome给127.0.0.1下发跨域请求
这种方式一直工作良好,今天有人搭建公网演示环境的时候发现报错了
查了一下,chrome官方说明如下:Private Network Access update: Introducing a deprecation trial ,简单的说,chrome认为从公网访问私网的http请求时不安全的,即使允许跨域也会报错。
那些地址会受影响呢,列表如下:
Address block |
Name |
Reference |
Address space |
127.0.0.0/8 |
IPv4 Loopback |
[RFC1122] |
local |
10.0.0.0/8 |
Private Use |
[RFC1918] |
private |
172.16.0.0/12 |
Private Use |
[RFC1918] |
private |
192.168.0.0/16 |
Private Use |
[RFC1918] |
private |
169.254.0.0/16 |
Link Local |
[RFC3927] |
private |
::1/128 |
IPv6 Loopback |
[RFC4291] |
local |
fc00::/7 |
Unique Local |
[RFC4193] |
private |
fe80::/10 |
Link-Local Unicast |
[RFC4291] |
private |
::ffff:0:0/96 |
IPv4-mapped |
[RFC4291] |
see mapped IPv4 address |
也就是说,如果从公网访问上表中的ip地址,不管是否允许跨域,都会报跨域问题。
解决方案:
chrome官方给的方案为:
- Upgrade both ends to HTTPS.
- Use WebTransport to securely connect to the target server.
- Reverse the embedding relationship.
不过升级https有些麻烦,找了一下,目前可以用一些临时方案解决。
临时方案:
- 打开 tab 页面 chrome://flags/#block-insecure-private-network-requests
- 将其 Block insecure private network requests 设置为 Disabled, 然后重启就行了, 这样子就相当于把这个功能禁用掉
这个方案也知道chrome101以前的版本有效,预计到明年5月份,先暂时采用这个方案吧,后续有其它方式再来更新此文章。
其它资料:
网上也有不少文章更深入分析了这个影响: