Communicating from Chrome 94 with LAN devices that do not support HTTPS from a web app-CodePudding

We developed a web application that communicates with a printer connected to the same LAN, by sending it POST requests.

Such printer has a server open on port 80 that takes XML containing the commands.

It's not possible to communicate with network devices from a page loaded via HTTPS; as such we used a workaround to keep communicating with it: We open a plain http:// popup and use it as a proxy (using postMessage) to send requests on the page's behalf, effectively functioning as a proxy.

This solution currently works on Firefox, but stopped working on the latest Chrome versions (>91?).

By "stopped working" I mean that the requests error out with net::ERR_FAILED, this only happens on some devices - for example, my Ubuntu machine running Chrome 94.

We could develop a desktop or mobile application merely to serve as a proxy with the printer or distribute the web app itself as an Electron application with CORS disabled, but both solutions sound downright awful and bloated for the end user compared to something that "just works" on every single device with a browser installed.

In summary, what is the proper way, in 2021, to communicate with network devices that don't support HTTPS from an HTTPS page?

CodePudding user response：

As per @sideshowbarker's comment, it's due to the new Private Access Network policies included in Chrome 94 and Edge Chromium.

Simply put, they restrict the ability of websites to communicate with devices on the local network.

Most of our customers are on Windows, so as a temporary workaround we disabled the new restrictions using a simple .reg file they can double click on and apply:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"InsecurePrivateNetworkRequestsAllowed"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome]
"InsecurePrivateNetworkRequestsAllowed"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"InsecurePrivateNetworkRequestsAllowed"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Edge]
"InsecurePrivateNetworkRequestsAllowed"=dword:00000001

We have found no such workaround for devices running iOS.

This disables this new safety feature, so keep in mind it comes with some safety issues.

To solve the problem in a definitive way, we contacted the manufacturer for the device we're communicating with and they're gonna start selling an external piece of hardware, which supports https. We can communicate with that instead, without having to upgrade the whole device.

If the manufacturer can't help, something like a Raspberry Pi can be used for the same purpose.