由於高版本的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月份,先暫時採用這個方案吧,後續有其它方式再來更新此文章。
其它資料:
網上也有不少文章更深入分析了這個影響: