Chcę przetestować pracowników usług, ale mam konfigurację wirtualnego hosta i nie mogę włączyć protokołu HTTPS na hoście lokalnym.
Jak mogę dodać do białej listy mój lokalny adres URL hosta wirtualnego, aby testować pracowników usług, gdy próbuję zarejestrować się dla pracownika Service Worker na hoście lokalnym? Chrome mówi, że protokół HTTPS jest wymagany do włączenia pracownika usługi. Jak mogę ominąć to ograniczenie, przynajmniej w przypadku testów lokalnych.
Odpowiedzi:
Ogólnie rzecz biorąc, musisz udostępniać zarówno swoją stronę, jak i skrypt modułu Service Worker za pośrednictwem protokołu HTTPS, aby móc korzystać z mechanizmów Service Worker. Uzasadnienie jest opisane w Preferuj bezpieczne źródła dla potężnych nowych funkcji .
Istnieje wyjątek od wymogu HTTPS w celu ułatwienia lokalnego programowania: jeśli uzyskujesz dostęp do swojej strony i skryptu narzędzia Service Worker za pośrednictwem http://localhost[:port]lub przez http://127.x.y.z[:port], pracownicy usług powinni być włączeni bez żadnych dalszych działań.
W najnowszych wersjach przeglądarki Chrome można obejść to wymaganie podczas lokalnego programowania za pośrednictwem chrome://flags/#unsafely-treat-insecure-origin-as-secure, jak wyjaśniono w tej odpowiedzi .
Firefox oferuje podobną funkcjonalność poprzez devtools.serviceWorkers.testing.enabledustawienie.
Należy pamiętać, że ta funkcja ma na celu jedynie ułatwienie testów, które w innym przypadku nie byłyby możliwe, i należy zawsze planować korzystanie z protokołu HTTPS podczas udostępniania produkcyjnej wersji witryny. Nie proś prawdziwych użytkowników, aby wykonali kroki włączania tych flag!
devtools.serviceWorkers.testing.enabled.
Jeśli chcesz zdebugować pracownika serwisu podłączonego urządzenia mobilnego w celu rzeczywistego testowania zachowania progresywnej aplikacji internetowej, opcje uruchamiania chrome ssl nie pomagają i zdecydowanie nie musisz kupować certyfikatów.
@ chris-ruppel wspomniał o instalowaniu oprogramowania proxy, ale w rzeczywistości istnieje łatwiejszy sposób wykorzystania przekierowania portów :
Zakładając, że łączysz się i debugujesz urządzenie za pomocą przeglądarki Chrome:
Po wykonaniu tej czynności możesz zadzwonić pod adres URL „ http: // localhost: 8080 ” na swoim urządzeniu mobilnym , a odpowiedź zostanie odebrana przez „localhost: 80” na Twoim rzeczywistym komputerze / serwerze testowym . Doskonale współpracuje z pracownikami usług, tak jakby była to lokalna maszyna działająca na telefonie komórkowym.
Działa również w przypadku wielu przekierowań portów i różnych domen docelowych, o ile pamiętasz o korzystaniu z nieuprzywilejowanych portów na urządzeniu mobilnym. Zobacz zrzut ekranu:
Źródłem tych informacji jest dokumentacja urządzeń zdalnych Google: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (ale od kwietnia 2017 r. Nie jest jasne, czy to przeczytać prosta odpowiedź)
Często chcę debugować i testować na prawdziwym urządzeniu. Jedna z metod, które wymyśliłem, polega na kierowaniu ruchu sieciowego telefonu przez Charles Proxy podczas lokalnego programowania. W przeciwieństwie do wszystkich rozwiązań specyficznych dla Chrome, działa to z każdą przeglądarką w telefonie.
localhostna moim urządzeniu mobilnym umożliwia teraz rejestrację i przetestowanie narzędzia Service Worker.Najłatwiejszym sposobem przetestowania pwa w moim przypadku było użycie ngrok. https://ngrok.com/download zaloguj się, pobierz swój token i ustaw go!
Po uruchomieniu ./ngrok http {your server port}upewnij się, że używasz protokołu https, który zostanie wyświetlony w terminalu po uruchomieniu tego polecenia powyżej.
Możesz również użyć https://surge.sh , służy on do hostowania statycznej strony internetowej, jeśli odwiedzisz tutaj: https://surge.sh/help/securing-your-custom-domain-with-ssl będzie mógł zobacz, jak skonfigurować certyfikat ssl
Jeśli chcesz przetestować Service Workery na urządzeniu klienckim, które nie może uruchomić serwera WWW na hoście lokalnym, ogólna technika jest następująca:
Ale łatwiej to powiedzieć niż zrobić. W listopadowym AMA na Reddit, przedstawiciel Let's Encrypt przyznał, że HTTPS w prywatnej sieci LAN „to naprawdę trudne pytanie i myślę, że nikt nie znalazł jak dotąd satysfakcjonującej odpowiedzi”.
Typowe sposoby nadania komputerowi nazwy hosta obejmują nadanie mu stabilnego wewnętrznego adresu IP, który nie zmienia się codziennie lub za każdym razem, gdy wyłączasz i wyłączasz bramę internetową. Będziesz musiał skonfigurować serwer DHCP w swojej sieci, zwykle ten w twojej bramie, aby ustawić „rezerwację”, która kojarzy określony adres prywatny (zwykle w obrębie 10/8lub 192.168/16) z adresem MAC karty Ethernet twojej stacji roboczej. W tym celu przeczytaj instrukcję swojej bramy.
Teraz, gdy Twoja programistyczna stacja robocza ma stabilny adres IP, musisz tracić czas i pieniądze. Jeśli chcesz nauczyć się zaawansowanego wykorzystania DNS i OpenSSL i zainstalować certyfikat główny na wszystkich urządzeniach, z którymi planujesz testować:
Jeśli nie możesz dodać certyfikatu głównego lub kontrolować lokalnego DNS, na przykład jeśli planujesz testować z urządzeniami należącymi do innych osób (BYOD) lub z bardziej zablokowanymi przeglądarkami, które nie pozwalają użytkownikom na dodawanie zaufanych certyfikatów głównych, takich jak te w głównych konsole do gier wideo, będziesz potrzebować w pełni kwalifikowanej nazwy domeny (FQDN):
Arekord na prywatny adres IP swojej stacji roboczej. Dzięki temu programistyczna stacja robocza ma nazwę FQDN.dns-01wyzwanie, aby uzyskać certyfikat dla tej nazwy FQDN z urzędu certyfikacji Let's Encrypt.Jak Jeff wspomniał w pierwszej odpowiedzi, nie potrzebujesz protokołu HTTPS na poziomie hosta lokalnego do testowania elementów Service Workers. Pracownicy usług zarejestrują się i będą działać dobrze, o ile uzyskasz dostęp do domeny hosta lokalnego - bez protokołu HTTPS.
Gdy już przetestujesz swoją aplikację na hoście lokalnym i chcesz zobaczyć, jak naprawdę działa z https, najprostszym podejściem byłoby przesłanie aplikacji do GitHub. Możesz utworzyć domenę publiczną za darmo (i za pomocą HTTPS!).
Oto instrukcje: https://pages.github.com/
Myślę, że najłatwiejszym sposobem na przetestowanie pracownika usług jest znalezienie darmowego dostawcy usług hostingowych. Obecnie istnieje wiele witryn, które zapewniają darmowy hosting. możesz łatwo hostować swoją aplikację na tych bezpłatnych serwerach.
Używam głównie heroku i netlify . to jest darmowe i łatwe w użyciu.
Użyłem ngrok do tunelowania lokalnego adresu IP (tak naprawdę nie jest tak, ponieważ znajduje się w Google Colab) do publicznego.
Przechodząc do konsoli ngrok , widzę wszystkie utworzone tunele. Utworzyłem tylko jeden tunel dla localhost: port, ale tutaj są 2, jeden dla HTTP i drugi dla HTTPS (czyż nie jest to miłe?).
Jeśli przejdę do adresu https mojej aplikacji internetowej, na konsoli widzę
Ale jeśli przejdę pod adres http, na konsoli otrzymam
P: Czy możesz pracować z pracownikami usług, którzy potrzebują protokołu HTTP przez tunele do zdalnego komputera?
O: Najwyraźniej tak!
Kod stojący za tą rejestracją to (ważne, aby wiedzieć, gdzie się nie udaje):
// Here we register the SERVICE WORKER
IndexController.prototype._registerServiceWorker = function() {
console.log("1.Starting SW function.");
if (!navigator.serviceWorker) {
console.log("2.Browser is NOT compatible with SW or something is not working.");
return; }
console.log("2.Browser is compatible with SW.");
navigator.serviceWorker.register('/sw.js').then(function() {
console.log('3.Registration worked!');
}).catch(function() {
console.log('3.Registration failed!');
});
};
Aby było to bardziej skomplikowane, moja aplikacja internetowa korzystająca z Service Workers działa w Colab ( Google Colab ). Aplikacja internetowa działa na Node.js wewnątrz Colab.
Jeśli pracujesz z localhost, powinno być to dla Ciebie łatwiejsze, ponieważ wymóg https nie jest wymuszany podczas łączenia się z localhost (zgodnie z teorią). [A] i [B]
To nie to samo, że przeglądarka będzie dobrze współpracować z Twoją aplikacją tylko dlatego, że działa na hoście lokalnym.
Uwaga: mój eksperyment powyżej ...
Przechodząc do aplikacji internetowej https, dostałem:
IndexController.js:49 Mixed Content: The page at 'https://0a4e1e0095b0.ngrok.io/' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://0a4e1e0095b0.ngrok.io/updates?since=1602934673264&'. This request has been blocked; this endpoint must be available over WSS.
IndexController._openSocket @ IndexController.js:49
IndexController @ IndexController.js:10
(anonymous) @ index.js:16
loadScripts @ loadScripts.js:5
46.../utils/loadScripts @ index.js:15
s @ _prelude.js:1
e @ _prelude.js:1
(anonymous) @ _prelude.js:1
IndexController.js:49 Uncaught DOMException: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.
at IndexController._openSocket (https://0a4e1e0095b0.ngrok.io/js/main.js:2251:12)
Przechodząc do aplikacji internetowej http, dostałem:
Navigated to http://0a4e1e0095b0.ngrok.io/
IndexController.js:17 1.Starting SW function.
IndexController.js:19 2.Browser is NOT compatible with SW or something is not working.
Jeśli nie jesteś na hoście lokalnym ORAZ nie możesz używać protokołu HTTPS, może być konieczna zmiana tych ustawień w przeglądarce.
Niektórzy już to wyjaśnili, ale to znowu się dzieje.
Chrom:
Pamiętaj, że spowoduje to ponowne uruchomienie wszystkich okien Chrome. Nie jest to dla mnie rozwiązanie, ponieważ moje tunele zmieniają nazwę za każdym razem, gdy są tworzone i nie mogę za każdym razem ponownie uruchamiać wielu okien.
Firefox / Waterfox
Firefox / Waterfox Prawdopodobnie nie musisz wprowadzać poniższych zmian, ale to zrobiłem (moja przeglądarka może być trochę stara). Więcej informacji tutaj .
W about: config
Włączyłem
dom.serviceWorkers.testing.enabled
dom.serviceWorkers.enabled
Gorąco polecam przejrzenie tej https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers i powiązanych stron w tej samej witrynie.
Jeśli ktoś jest zainteresowany konfiguracją ngrok, jest to bardzo proste (wersja dla Pythona).
# Install pyngrok python package on your Google Colab Session
!pip install pyngrok
# Set up your ngrok Authtoken (requires free registration)
!ngrok authtoken YOUR_TOKEN_HERE
# Invoke ngrok from Python and start tunneling/connecting
from pyngrok import ngrok
# Open a HTTP tunnel on the default port 80 if not specified
ngrok_tunnel = ngrok.connect('8888')
# You can print it, or go to the ngrok console on https://dashboard.ngrok.com/status/tunnels
print (ngrok_tunnel.public_url)