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