Desarrollamos una aplicación web que se comunica con una impresora conectada a la misma LAN, enviándole solicitudes POST.
Dicha impresora tiene un servidor abierto en el puerto 80 que toma el XML que contiene los comandos.
No es posible comunicarse con dispositivos de red desde una página cargada a través de HTTPS; como tal, usamos una solución alternativa para seguir comunicándonos con él: abrimos una ventana emergente http:// simple y la usamos como un proxy (usando postMessage) para enviar solicitudes en nombre de la página, funcionando efectivamente como un proxy.
Esta solución actualmente funciona en Firefox, pero dejó de funcionar en las últimas versiones de Chrome (>91?).
Por "dejó de funcionar" quiero decir que las solicitudes fallaron con net::ERR_FAILED , esto solo ocurre en algunos dispositivos, por ejemplo, mi máquina Ubuntu que ejecuta Chrome 94.
Podríamos desarrollar una aplicación de escritorio o móvil simplemente para que sirva como un proxy con la impresora o distribuir la aplicación web como una aplicación Electron con CORS desactivado, pero ambas soluciones suenan francamente horribles e infladas para el usuario final en comparación con algo que "simplemente funciona". " en todos los dispositivos con un navegador instalado.
En resumen, ¿cuál es la forma correcta, en 2021, de comunicarse con dispositivos de red que no admiten HTTPS desde una página HTTPS ?
Según el comentario de @sideshowbarker, se debe a las nuevas políticas de Red de acceso privado incluidas en Chrome 94 y Edge Chromium.
En pocas palabras, restringen la capacidad de los sitios web para comunicarse con dispositivos en la red local.
ACTUALIZACIÓN: Lo siguiente no es necesario. Después de algunas investigaciones, aparentemente es suficiente configurar "Bloquear solicitudes de red privada inseguras". marca a "Deshabilitado" en chrome://flags . Esto también funciona en dispositivos OSX, Android, iOS y Linux, a diferencia de la solución alternativa del Registro de Windows.
Solución anterior a continuación.
La mayoría de nuestros clientes utilizan Windows, por lo que, como solución temporal, deshabilitamos las nuevas restricciones mediante un simple archivo .reg en el que pueden hacer doble clic y aplicar:
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:00000001Esto desactiva esta nueva característica de seguridad, así que tenga en cuenta que viene con algunos problemas de seguridad.
Para solucionar el problema de forma definitiva, contactamos con el fabricante del dispositivo con el que nos estamos comunicando y van a empezar a vender un hardware externo, que soporte https. En cambio, podemos comunicarnos con eso, sin tener que actualizar todo el dispositivo.
Si el fabricante no puede ayudar, se puede usar algo como una Raspberry Pi para el mismo propósito.