J'ai un serveur de développeur utilisé pour les tests. Ils ont des certificats SSL auto-signés, qui nous permettent de tester l'application Web via HTTPS, mais avec des avertissements évidents que les certificats ne sont pas vérifiables.
C'est bien, mais j'ai un agent de service qui jette une erreur avec le navigator.serviceWorker.register
SecurityError: impossible d'inscrire ServiceWorker: une erreur de certificat SSL s'est produite lors de l'extraction du script.
Comment utiliser un Service Worker avec un serveur de test intranet doté d'un certificat auto-signé?
Au lieu d'utiliser des certificats auto-signés, vous pouvez lancer Chrome ou Firefox de sorte que certains domaines soient sécurisés. Par exemple, en utilisant Chrome sur une Mac, vous pouvez le lancer en utilisant:
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ --user-data-dir=/tmp/foo --unsafely-treat-insecure-Origin-as-secure=http://www.your.site
Les ouvriers de service devraient alors travailler de http://www.your.site .
Plus d'informations peuvent être trouvées ici: Options pour tester les agents de maintenance via HTTP
Edit: Modifié --unsafety-...
à --unsafely-...
La réponse acceptée ci-dessus n'a pas fonctionné pour moi. J'ai ajouté le --ignore-certificate-errors à celui suggéré par @ stef52 pour cette question Erreur lors de l'enregistrement du technicien de service et cela a fonctionné
chrome.exe --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-Origin-as-secure=https://localhost/
OU pour les utilisateurs MAC
./Google\ Chrome --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-Origin-as-secure=https://localhost
Pour le développement local, nous utilisons des certificats auto-signés. Résoudre les problèmes liés au développement local sur OSX. Nous avons fait ce qui suit:
Cette réponse répète certains points de Chucks.
Si cette exception DomException spécifique s'est produite localement sur un port d'adresse, lors de l'accès à une ressource Web sur une machine locale, l'une de ces dernières versions de lancements de navigateur peut avoir aidé:
open -a Opera.app --args --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-Origin-as-secure=https://localhost:8111
open -a Brave\ Browser.app --args --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-Origin-as-secure=https://localhost:8111
open -a Google\ Chrome.app --args --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-Origin-as-secure=https://localhost:8111
Le navigateur Chromium n'a pas démarré avec ces paramètres pour permettre de surmonter cette exception DomException spécifique liée à l'utilisation de SSL avec un agent de service localement.
Cette personne a également fourni quelques informations à ce sujet: https://deanhume.com/testing-service-workers-locally-with-self-sign-certificates/
Pour moi, ignorer les certificats ou définir l'indicateur d'origine non sécurisé pour le périphérique mobile ne fonctionnait pas.
Cependant, portforwarding a fait l'affaire. Les employés du service après-vente sont autorisés à s’exécuter sur localhost, qu’il soit signé avec un certificat et qu’il communique via SSL. Vous laissez donc votre appareil mobile penser qu’il s’exécute sur localhost mais vous le transférez au véritable localhost sur le serveur. Ceci peut être réalisé par chacune de ces 2 méthodes: