javascript - body - Opciones para probar trabajadores de servicio a través de HTTP

meta html

Question

Quiero probar a los trabajadores de servicio, pero tengo una configuración de host virtual y parece que no puedo habilitar https en localhost.

¿Cómo puedo incluir en la lista blanca la URL de mi host virtual local para probar a los trabajadores de servicio cada vez que intento registrarme para el trabajador de servicio en el host local? Chrome dice que se requiere https para habilitar el trabajador de servicio. ¿Cómo puedo superar esta restricción al menos para las pruebas locales?

Answer 1

A menudo quiero depurar y probar en un dispositivo real. Un método que se me ocurrió implica enrutar el tráfico de red del teléfono a través de Charles Proxy durante el desarrollo local. A diferencia de todas las soluciones específicas de Chrome, esto funciona con cualquier navegador en su teléfono.

1. Ejecute Charles en mi computadora portátil (que también sirve mi sitio web con el Service Worker). Una vez que Charles se esté ejecutando, tenga en cuenta la IP / puerto para el Paso 2.
2. Configurar el dispositivo móvil para usar mi computadora portátil como proxy.
   • Para Android, solo toque y mantenga presionado su WiFi en Configuración> Modificar red > Configuración avanzada > Proxy . Use el Manual para configurar la IP / puerto.
   • Para iOS, haga clic en el icono (i)> sección Proxy HTTP . Seleccione Manual , luego configure la IP / puerto.
3. Visitar localhost en mi dispositivo móvil ahora permite registrar y probar al Service Serviceer.

Answer 2

Como Jeff mencionó en la primera respuesta, no necesita https en el nivel de host local para probar los trabajadores de servicio. Los trabajadores de servicio se registrarán y trabajarán correctamente siempre que acceda al dominio localhost, sin HTTPS.

Una vez que haya probado su aplicación en localhost y desee ver cómo funciona con https de verdad, el enfoque más simple sería subir su aplicación a GitHub. Puede crear un dominio público de forma gratuita (¡y con HTTPS!).

Aquí están las instrucciones: https://pages.github.com/

Answer 3

Creo que la forma más fácil de evaluar a los trabajadores de servicios es encontrar un proveedor de alojamiento gratuito. Hoy en día, hay muchos sitios que ofrecen alojamiento gratuito. puede alojar fácilmente su aplicación en estos servidores gratuitos.

Principalmente uso heroku y netlify . Estos son gratuitos y fáciles de usar.

Answer 4

En general, debe servir tanto su página como su script de trabajador de servicio a través de HTTPS para poder usar trabajadores de servicio. La justificación se describe en Prefer Secure Origins para nuevas y potentes funciones .

Existe una excepción al requisito de HTTPS para facilitar el desarrollo local: si accede a su página y al script del trabajador de servicio a través de http://localhost[:port] , o a través de http://127.xyz[:port] , entonces el servicio los trabajadores deberían estar habilitados sin ninguna otra acción.

Si, por alguna razón, necesita acceder a su servidor web local a través de un nombre de host que no sea localhost o 127.xyz , o si necesita probar cosas en un servidor web remoto que no es compatible con HTTPS, hay una solución manual que puedo usar. Implica iniciar Chrome a través de la línea de comando y usar los --user-data-dir y --unsafely-treat-insecure-origin-as-secure .

Este error tiene más detalles, incluido un ejemplo completo de cómo iniciar Chrome.

Firefox ofrece una funcionalidad similar , a través de la configuración devtools.serviceWorkers.testing.enabled .

Tenga en cuenta que esta funcionalidad solo está destinada a facilitar las pruebas que de otro modo no podrían llevarse a cabo, y siempre debe planear usar HTTPS cuando publique la versión de producción de su sitio. ¡No les pidas a usuarios reales que sigan los pasos para habilitar esas banderas!

Answer 5

La forma más fácil de probar pwa, en mi caso, estaba usando ngrok. https://ngrok.com/download inicie sesión, obtenga su token y configúrelo.

Cuando ejecute ./ngrok http {your server port} asegúrese de utilizar https, que se mostrará en el terminal después de ejecutar este comando anterior.

También puede usar https://surge.sh , es para alojar una página web estática, si visita aquí: https://surge.sh/help/securing-your-custom-domain-with-ssl podrá ver cómo configurar un certificado SSL

Answer 6

Si desea depurar el trabajador de servicio de un dispositivo móvil conectado para una prueba de comportamiento real de una aplicación web progresiva, las opciones de inicio de ssl chrome no ayudan y definitivamente no necesita comprar certificados.

@ chris-ruppel mencionó la instalación del software proxy, pero en realidad hay una manera más fácil de usar el reenvío de puertos :

Suponiendo que conecta y depura su dispositivo usando Chrome:

• En Chrome Dev Tools "Dispositivos remotos", abra "Configuración" y agregue una regla de "Reenvío de puertos" .
• Si su configuración localhost se ejecuta en localhost: 80,
• simplemente agregue una regla "Puerto de dispositivo 8080" (puede ser cualquier puerto sin privilegios> 1024)
• y la dirección local "localhost: 80" (o mytestserver.sometestdomainwithoutssl.company:8181 o lo que sea)

Después de hacer eso, puede llamar a la URL " http: // localhost: 8080 " en su dispositivo móvil y será respondida por "localhost: 80" en su PC / servidor de prueba real . Funciona perfectamente con los trabajadores de servicio como si fuera su máquina local ejecutándose en su dispositivo móvil.

Funciona también para múltiples reenvíos de puertos y diferentes dominios de destino, siempre que recuerde usar puertos no privilegiados en su dispositivo móvil. Ver captura de pantalla:

La fuente de esta información es la documentación de dispositivos remotos de Google: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (pero a partir de abril de 2017 no es muy claro leer esto respuesta simple fuera de eso)

Answer 7

Si desea probar los trabajadores de servicio en un dispositivo cliente que no puede ejecutar un servidor web en localhost, la técnica general es la siguiente:

1. Déle a su servidor un nombre de host.
2. Dele a este nombre de host un certificado.
3. Haga que las IP confíen en la CA que emitió este certificado.

Pero esto es más fácil decirlo que hacerlo. En un AMA de noviembre de 2016 en Reddit, un representante de Let''s Encrypt acknowledged que HTTPS en una LAN privada "es una pregunta realmente difícil, y creo que hasta ahora nadie ha encontrado una respuesta satisfactoria".

Las formas comunes de darle a su computadora un nombre de host implica darle una dirección IP interna estable, no una que cambie diariamente o cada vez que apague y encienda su dispositivo de puerta de enlace a Internet. Deberá configurar el servidor DHCP en su red, generalmente en su puerta de enlace, para configurar una "reserva" que asocie una dirección privada en particular (generalmente dentro de 10/8 o 192.168/16 ) con la dirección MAC de su desarrollo tarjeta Ethernet de la estación de trabajo. Para esto, lea el manual de su puerta de enlace.

Ahora que su estación de trabajo de desarrollo tiene una dirección IP estable, hay una compensación de tiempo / dinero. Si está dispuesto a aprender el uso avanzado de DNS y OpenSSL e instalar un certificado raíz en todos los dispositivos con los que planea probar:

1. Ejecute un servidor DNS interno en su red. Esto podría estar en su puerta de enlace o en su estación de trabajo de desarrollo.
2. Configure su servidor DNS para que tenga autoridad para algunos TLD inventados y sea recursivo para otros TLD.
3. Dé un nombre estable a la dirección IP privada de su estación de trabajo de desarrollo. Esto le da un nombre interno.
4. Configure su servidor DHCP para dar la dirección de este servidor DNS a otros dispositivos que obtengan arrendamientos.
5. En su estación de trabajo de desarrollo, use OpenSSL para generar pares de claves para una autoridad de certificación privada y el servidor web.
6. Con OpenSSL, emita un certificado raíz para la CA y un certificado para el nombre interno del servidor web.
7. Configure HTTPS en el servidor web en su estación de trabajo de desarrollo utilizando este certificado.
8. Instale el certificado raíz de la CA como un certificado raíz de confianza en todos los dispositivos.
9. En todos los dispositivos, acceda a este nombre interno.

Si no puede agregar un certificado raíz o controlar el DNS local, como si planea probar con dispositivos propiedad de otros (BYOD) o con más navegadores bloqueados que no permiten a los usuarios agregar certificados raíz confiables, como los de mayor consolas de videojuegos, necesitará un nombre de dominio completo (FQDN):

1. Compre un dominio de un registrador que ofrezca DNS con una API . Esto podría estar directamente dentro de un TLD o de uno de los proveedores de DNS dinámico que lo ha incluido en la Lista de sufijos públicos. (Los proveedores de DNS dinámico no PSL son inaceptables debido a los límites de velocidad impuestos por Let''s Encrypt ).
2. En el archivo de zona de este dominio, apunte un registro A a la dirección IP privada de su estación de trabajo de desarrollo. Esto le da a su estación de trabajo de desarrollo un FQDN.
3. Use Dehydrated , un cliente ACME que admite el desafío dns-01 , para obtener un certificado para este FQDN de la autoridad de certificación Let''s Encrypt.
4. Configure HTTPS en el servidor web en su estación de trabajo de desarrollo utilizando este certificado.
5. En todos los dispositivos, acceda a este nombre.