Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

236
Visualizações
Communicating from Chrome 94+ with LAN devices that do not support HTTPS from a web app

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?

about 4 years ago · Juan Pablo Isaza
1 Respostas
Responde à pergunta

0

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.

about 4 years ago · Juan Pablo Isaza Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda