2

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?

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Hissvard
  • 488
  • 7
  • 24
  • 1
    See the answer at https://stackoverflow.com/a/69348232/441757. This may be related to Chrome 94 now enforcing Private Network Access restrictions. See https://developer.chrome.com/blog/private-network-access-update/ – sideshowbarker Sep 27 '21 at 23:01
  • Thanks a lot, I will add an answer myself just in case someone pops up here from Google. – Hissvard Sep 29 '21 at 07:24

1 Answers1

4

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.

UPDATE: The following is not necessary. After some research, it's apparently enough to set the "Block insecure private network requests." flag to "Disabled" in chrome://flags. This works on OSX, Android, iOS and Linux devices too, as opposed to the Windows Registry workaround.

Previous solution below.

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

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.

Hissvard
  • 488
  • 7
  • 24