Options pour tester les agents de service via HTTP

Je veux tester les techniciens de service mais j'ai une configuration d'hôte virtuel et je n'arrive pas à pouvoir activer https sur localhost.

Comment puis-je mettre sur liste blanche l'URL de mon hôte virtuel local pour tester les techniciens de service chaque fois que j'essaie de m'inscrire au service worker sur l'hôte local? Chrome indique que https est requis pour activer le service worker. Comment puis-je dépasser cette restriction au moins pour les tests locaux.

En général, vous devez servir à la fois votre page et votre script de service worker via HTTPS afin d'utiliser les services workers. La justification est décrite dans Préférez les origines sécurisées pour de nouvelles fonctionnalités puissantes .

Il existe une exception à l'exigence HTTPS en place pour faciliter le développement local: si vous accédez à votre page et au script de service worker via http://localhost[:port]ou via http://127.x.y.z[:port], alors les techniciens de service doivent être activés sans aucune autre action.

Dans les versions récentes de Chrome, vous pouvez contourner cette exigence pendant le développement local via chrome://flags/#unsafely-treat-insecure-origin-as-secure, comme expliqué dans cette réponse .

Firefox offre des fonctionnalités similaires , via le devtools.serviceWorkers.testing.enabledparamètre.

Veuillez noter que cette fonctionnalité est uniquement destinée à faciliter les tests qui ne pourraient autrement pas avoir lieu, et vous devez toujours prévoir d'utiliser HTTPS lors de la diffusion de la version de production de votre site. Ne demandez pas à de vrais utilisateurs de suivre les étapes d'activation de ces indicateurs!

Si vous souhaitez déboguer le service worker d'un appareil mobile branché pour un test de comportement réel d'une application Web progressive, les options de démarrage ssl chrome n'aident pas et vous n'avez certainement pas besoin d'acheter des certificats.

@ chris-ruppel a mentionné l'installation d'un logiciel proxy, mais il existe en fait un moyen plus simple d'utiliser la redirection de port :

En supposant que vous vous connectez et déboguez votre appareil à l'aide de Chrome:

• Dans les "Appareils distants" des outils de développement Chrome, ouvrez "Paramètres" et ajoutez une règle "Transfert de port" .
• Si votre configuration d'hôte local s'exécute sur localhost: 80,
• il suffit d'ajouter une règle "Device port 8080" (peut être n'importe quel port non autorisé> 1024)
• et l'adresse locale "localhost: 80" (ou mon serveur de test.un certain domaine sans société.sl: 8181 ou autre)

Après cela, vous pouvez appeler l'URL " http: // localhost: 8080 " sur votre appareil mobile et il sera répondu par le "localhost: 80" sur votre PC / serveur de test actuel . Fonctionne parfaitement avec les techniciens de service comme s'il s'agissait de votre machine locale fonctionnant sur votre mobile.

Fonctionne également pour plusieurs redirections de port et différents domaines cibles tant que vous vous souvenez d'utiliser des ports non privilégiés sur votre appareil mobile. Voir la capture d'écran:

La source de cette information est la documentation des appareils distants de Google: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (mais en avril 2017, il n'est pas très clair de lire ceci réponse simple)

Je souhaite souvent déboguer et tester sur un appareil réel. Une méthode que j'ai trouvée consiste à acheminer le trafic réseau du téléphone via Charles Proxy pendant le développement local. Contrairement à toutes les solutions spécifiques à Chrome, cela fonctionne avec n'importe quel navigateur de votre téléphone.

1. Exécutez Charles sur mon ordinateur portable (qui sert également mon site Web avec le Service Worker). Une fois que Charles est en cours d'exécution, notez l'adresse IP / le port pour l'étape 2.
2. Configurez l'appareil mobile pour utiliser mon ordinateur portable comme proxy.
   • Pour Android, appuyez et maintenez simplement votre WiFi dans les paramètres> Modifier le réseau > Paramètres avancés > Proxy . Utilisez Manuel pour définir l'IP / le port.
   • Pour iOS, cliquez sur l'icône (i)> section Proxy HTTP . Sélectionnez Manuel , puis définissez l'IP / le port.
3. Visiter localhostsur mon appareil mobile permet maintenant au technicien de service d'être enregistré et testé.

Le moyen le plus simple de tester pwa, dans mon cas, était d'utiliser ngrok. https://ngrok.com/download connectez-vous, obtenez votre jeton et configurez-le!

Lorsque vous exécutez, ./ngrok http {your server port}assurez-vous que vous utilisez https qui sera affiché dans le terminal après avoir exécuté cette commande ci-dessus.

Vous pouvez également utiliser https://surge.sh , c'est pour héberger une page Web statique, si vous visitez ici: https://surge.sh/help/securing-your-custom-domain-with-ssl pourra voir comment configurer un certificat SSL

Comme Jeff l'a mentionné dans la première réponse, vous n'avez pas besoin de https au niveau localhost pour tester les Service Workers. Les techniciens de service s'enregistreront et fonctionneront très bien tant que vous accédez au domaine localhost - sans HTTPS.

Une fois votre application testée sur localhost et que vous souhaitez voir comment cela fonctionne avec https pour de vrai, l'approche la plus simple serait de télécharger votre application sur GitHub. Vous pouvez créer un domaine public gratuitement (et avec HTTPS!).

Voici les instructions: https://pages.github.com/

Si vous souhaitez tester les techniciens de service sur une machine cliente qui ne peut pas exécuter un serveur Web sur l'hôte local, la technique générale est la suivante:

1. Donnez à votre serveur un nom d'hôte.
2. Donnez à ce nom d'hôte un certificat.
3. Faites en sorte que les adresses IP approuvent l'autorité de certification qui a émis ce certificat.

Mais c'est plus facile à dire qu'à faire. Dans une AMA de novembre 2016 sur Reddit, un représentant de Let's Encrypt a reconnu que HTTPS sur un réseau local privé "est une question vraiment difficile, et je pense que personne n'a encore trouvé de réponse satisfaisante".

Les méthodes courantes pour attribuer un nom d'hôte à votre ordinateur consistent à lui donner une adresse IP interne stable, et non une adresse qui change quotidiennement ou à chaque fois que vous redémarrez votre appliance de passerelle Internet. Vous devrez configurer le serveur DHCP sur votre réseau, généralement celui de votre passerelle, pour mettre en place une "réservation" qui associe une adresse privée particulière (généralement dans 10/8ou 192.168/16) à l'adresse MAC de la carte Ethernet de votre poste de développement. Pour cela, lisez le manuel de votre passerelle.

Maintenant que votre poste de travail de développement a une adresse IP stable, il y a un compromis temps / argent. Si vous souhaitez apprendre l'utilisation avancée du DNS et d'OpenSSL et installer un certificat racine sur tous les appareils avec lesquels vous prévoyez de tester:

1. Exécutez un serveur DNS interne sur votre réseau. Cela peut être sur votre passerelle ou sur votre poste de travail de développement.
2. Configurez votre serveur DNS pour qu'il fasse autorité pour certains TLD inventés et récursif pour d'autres TLD.
3. Donnez un nom stable à l'adresse IP privée de votre poste de travail de développement. Cela lui donne un nom interne.
4. Configurez votre serveur DHCP pour donner l'adresse de ce serveur DNS aux autres appareils obtenant des baux.
5. Sur votre poste de travail de développement, utilisez OpenSSL pour générer des paires de clés pour une autorité de certification privée et le serveur Web.
6. À l'aide d'OpenSSL, émettez un certificat racine pour l'autorité de certification et un certificat pour le nom interne du serveur Web.
7. Configurez HTTPS dans le serveur Web de votre poste de travail de développement à l'aide de ce certificat.
8. Installez le certificat racine de l'autorité de certification en tant que certificat racine approuvé sur tous les appareils.
9. Sur tous les appareils, accédez à ce nom interne.

Si vous ne pouvez pas ajouter un certificat racine ou contrôler le DNS local, par exemple si vous prévoyez de tester avec des appareils appartenant à d'autres (BYOD) ou avec des navigateurs plus verrouillés qui ne permettent pas aux utilisateurs d'ajouter des certificats racine de confiance, tels que ceux des principaux consoles de jeux vidéo, vous aurez besoin d'un nom de domaine complet (FQDN):

1. Achetez un domaine auprès d'un registraire qui propose un DNS avec une API . Cela peut être directement dans un TLD ou depuis l'un des fournisseurs DNS dynamiques qui l'ont fait sur la liste publique des suffixes. (Les fournisseurs DNS dynamiques non PSL sont inacceptables en raison des limites de débit imposées par Let's Encrypt .)
2. Dans le fichier de zone de ce domaine, pointez un Aenregistrement sur l'adresse IP privée de votre poste de travail de développement. Cela donne à votre poste de travail de développement un FQDN.
3. Utilisez Dehydrated , un client ACME qui prend en charge le dns-01défi, pour obtenir un certificat pour ce FQDN auprès de l'autorité de certification Let's Encrypt.
4. Configurez HTTPS dans le serveur Web de votre poste de travail de développement à l'aide de ce certificat.
5. Sur tous les appareils, accédez à ce nom.

Je pense que le moyen le plus simple de tester le service worker est de trouver un fournisseur d'hébergement gratuit. de nos jours, de nombreux sites proposent un hébergement gratuit. vous pouvez facilement héberger votre application sur ces serveurs gratuits.

J'utilise principalement heroku et netlify . ce sont gratuits et faciles à utiliser.