由于高版本的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月份,先暂时采用这个方案吧,后续有其它方式再来更新此文章。
其它资料:
网上也有不少文章更深入分析了这个影响: