Opções para testar service workers via HTTP

Quero testar service workers, mas tenho uma configuração de host virtual e não consigo habilitar https no localhost.

Como posso colocar na lista de permissões meu url de host virtual local para testar os service workers sempre que tento me registrar para o service worker no localhost? O Chrome diz que https é necessário para habilitar o service worker. Como posso superar essa restrição pelo menos para testes locais.

Em geral, você precisa veicular sua página e o script do service worker via HTTPS para usar service workers. A justificativa é descrita em Preferir origens seguras para novos recursos poderosos .

Há uma exceção ao requisito de HTTPS para facilitar o desenvolvimento local: se você acessar sua página e o script do service worker por meio http://localhost[:port]ou via http://127.x.y.z[:port], os service workers devem ser ativados sem nenhuma ação adicional.

Em versões recentes do Chrome, você pode contornar esse requisito durante o desenvolvimento local via chrome://flags/#unsafely-treat-insecure-origin-as-secure, conforme explicado nesta resposta .

O Firefox oferece funcionalidade semelhante , por meio da devtools.serviceWorkers.testing.enabledconfiguração.

Observe que esta funcionalidade é apenas para facilitar o teste que de outra forma não seria possível, e você deve sempre planejar o uso de HTTPS ao veicular a versão de produção do seu site. Não peça aos usuários reais para seguirem as etapas de habilitação desses sinalizadores!

Se você deseja depurar um service worker de um dispositivo móvel conectado de um para um teste de comportamento real de um aplicativo da web progressivo, as opções de início do ssl chrome não ajudam e você definitivamente não precisa comprar certificados.

@chris-ruppel mencionou a instalação de software proxy, mas na verdade existe uma maneira mais fácil de usar o encaminhamento de porta :

Supondo que você conecte e depure seu dispositivo usando o Chrome:

• No Chrome Dev Tools "Remote devices", abra "Settings" e adicione uma regra de "Port forwarding" .
• Se a configuração do host local estiver em execução no host local: 80,
• basta adicionar uma regra "Porta do dispositivo 8080" (pode ser qualquer porta não privilegiada> 1024)
• e o endereço local "localhost: 80" (ou mytestserver.sometestdomainwithoutssl.company:8181 ou qualquer outro)

Depois de fazer isso, você pode chamar o URL " http: // localhost: 8080 " no seu celular dispositivo e será respondido por "localhost: 80" em seu PC / servidor de teste real . Funciona perfeitamente com service workers como se fosse sua máquina local rodando em seu celular.

Funciona também para múltiplos encaminhamentos de porta e diferentes domínios de destino, desde que você se lembre de usar portas sem privilégios em seu dispositivo móvel. Veja a imagem:

A fonte dessas informações é a documentação dos dispositivos remotos do Google: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (mas desde abril de 2017 não é muito claro ler isso resposta simples fora disso)

Freqüentemente, desejo depurar e testar em um dispositivo real. Um método que descobri envolve o roteamento do tráfego de rede do telefone por meio do Charles Proxy durante o desenvolvimento local. Ao contrário de todas as soluções específicas do Chrome, isso funciona com qualquer navegador do telefone.

1. Execute o Charles no meu laptop (que também atende meu site com o Service Worker). Quando o Charles estiver em execução, anote o IP / porta para a Etapa 2.
2. Configure o dispositivo móvel para usar meu laptop como proxy.
   • Para Android, basta tocar e segurar em seu WiFi em configurações> Modificar rede > Configurações avançadas > Proxy . Manual de uso para definir o IP / porta.
   • Para iOS, clique no ícone (i)> seção Proxy HTTP . Selecione Manual e defina o IP / porta.
3. A visita localhostem meu dispositivo móvel agora permite que o Service Worker seja registrado e testado.

A maneira mais fácil de testar o pwa, no meu caso, era usando o ngrok. https://ngrok.com/download faça login, obtenha seu token e configure-o!

Ao executar, ./ngrok http {your server port}certifique-se de usar https, que será mostrado no terminal após a execução do comando acima.

Você pode usar https://surge.sh também, é para hospedar uma página da web estática, se você visitar aqui: https://surge.sh/help/securing-your-custom-domain-with-ssl será capaz de veja como configurar um certificado SSL

Como Jeff mencionou na primeira resposta, você não precisa de https no nível de host local para testar Service Workers. Os service workers se registrarão e funcionarão bem, desde que você acesse o domínio localhost - sem HTTPS.

Depois de testar seu aplicativo no localhost e quiser ver como ele funciona com https de verdade, a abordagem mais simples seria carregar seu aplicativo no GitHub. Você pode criar um domínio público gratuitamente (e com HTTPS!).

Aqui estão as instruções: https://pages.github.com/

Se você deseja testar service workers em um dispositivo cliente que não pode executar um servidor da web no localhost, a técnica geral é a seguinte:

1. Dê ao seu servidor um nome de host.
2. Dê um certificado a este nome de host.
3. Faça com que os IPs confiem na CA que emitiu este certificado.

Mas isso é mais fácil dizer do que fazer. Em um AMA de novembro de 2016 no Reddit, um representante do Let's Encrypt reconheceu que HTTPS em uma LAN privada "é uma pergunta realmente difícil e acho que ninguém apresentou uma resposta satisfatória até agora."

Maneiras comuns de dar ao seu computador um nome de host envolvem dar a ele um endereço IP interno estável, não um que mude diariamente ou toda vez que você reinicia o seu dispositivo de gateway de Internet. Você precisará configurar o servidor DHCP em sua rede, geralmente em seu gateway, para configurar uma "reserva" que associa um endereço privado específico (normalmente em 10/8ou192.168/16 ) com o endereço MAC da placa Ethernet da estação de trabalho de desenvolvimento. Para isso, leia o manual do seu gateway.

Agora que sua estação de trabalho de desenvolvimento tem um endereço IP estável, há uma troca de tempo / dinheiro. Se você deseja aprender o uso avançado de DNS e OpenSSL e instalar um certificado raiz em todos os dispositivos com os quais planeja testar:

1. Execute um servidor DNS interno em sua rede. Isso pode ser em seu gateway ou em sua estação de trabalho de desenvolvimento.
2. Configure seu servidor DNS para ser autoritativo para alguns TLDs inventados e recursivo para outros TLDs.
3. Dê um nome estável ao endereço IP privado da estação de trabalho de desenvolvimento. Isso dá a ele um nome interno.
4. Configure seu servidor DHCP para fornecer o endereço deste servidor DNS a outros dispositivos que obtenham concessões.
5. Em sua estação de trabalho de desenvolvimento, use OpenSSL para gerar pares de chaves para uma autoridade de certificação privada e o servidor web.
6. Usando OpenSSL, emita um certificado raiz para a CA e um certificado para o nome interno do servidor web.
7. Configure HTTPS no servidor da web em sua estação de trabalho de desenvolvimento usando este certificado.
8. Instale o certificado raiz da CA como um certificado raiz confiável em todos os dispositivos.
9. Em todos os dispositivos, acesse este nome interno.

Se você não pode adicionar um certificado raiz ou controlar o DNS local, como se você planeja testar com dispositivos de terceiros (BYOD) ou com mais navegadores bloqueados que não permitem que os usuários adicionem certificados raiz confiáveis, como os principais consoles de videogame, você precisará de um nome de domínio totalmente qualificado (FQDN):

1. Compre um domínio de um registrador que oferece DNS com uma API . Isso poderia ser diretamente dentro de um TLD ou de um dos provedores de DNS dinâmico que o incluiu na Lista Pública de Sufixos. (Provedores de DNS dinâmico não PSL são inaceitáveis ​​devido aos limites de taxa impostos por Let's Encrypt .)
2. No arquivo de zona deste domínio, aponte um A registro para o endereço IP privado da estação de trabalho de desenvolvimento. Isso fornece um FQDN à sua estação de trabalho de desenvolvimento.
3. Use o Dehydrated , um cliente ACME que suporta o dns-01desafio, para obter um certificado para este FQDN da autoridade de certificação Let's Encrypt.
4. Configure HTTPS no servidor da web em sua estação de trabalho de desenvolvimento usando este certificado.
5. Em todos os dispositivos, acesse este nome.

Acho que a maneira mais fácil de testar o service worker é encontrar um provedor de hospedagem gratuito. hoje em dia, existem muitos sites que oferecem hospedagem gratuita. você pode facilmente hospedar seu aplicativo nesses servidores gratuitos.

Eu uso principalmente heroku e netlify . isso é gratuito e fácil de usar.