Opcje testowania pracowników usług za pośrednictwem protokołu HTTP

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.

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!

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:

• W Narzędziach dla programistów Chrome „Urządzenia zdalne” otwórz „Ustawienia” i dodaj regułę „Przekierowanie portów” .
• Jeśli Twoja konfiguracja hosta lokalnego działa na hoście lokalnym: 80,
• wystarczy dodać regułę „Port urządzenia 8080” (może to być dowolny nieuprzywilejowany port> 1024)
• i adres lokalny „localhost: 80” (lub mytestserver.sometestdomainwithoutssl.company:8181 or other)

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.

1. Uruchom Charlesa na moim laptopie (który obsługuje również moją stronę internetową z Service Workerem). Po uruchomieniu Charles zanotuj adres IP / port dla kroku 2.
2. Skonfiguruj urządzenie mobilne, aby używać mojego laptopa jako serwera proxy.
   • W przypadku Androida wystarczy dotknąć i przytrzymać WiFi w ustawieniach> Modyfikuj sieć > Ustawienia zaawansowane > Proxy . Użyj opcji Ręcznie, aby ustawić adres IP / port.
   • W systemie iOS kliknij ikonę (i)> sekcję Serwer proxy HTTP . Wybierz opcję Ręcznie , a następnie ustaw adres IP / port.
3. Odwiedzenie 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:

1. Nadaj serwerowi nazwę hosta.
2. Nadaj tej nazwie hosta certyfikat.
3. Spraw, aby adresy IP ufały urzędowi certyfikacji, który wystawił ten certyfikat.

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ć:

1. Uruchom wewnętrzny serwer DNS w swojej sieci. Może to znajdować się na Twojej bramie lub na stacji roboczej deweloperskiej.
2. Skonfiguruj serwer DNS, aby był autorytatywny dla niektórych utworzonych TLD i rekurencyjny dla innych TLD.
3. Nadaj stabilną nazwę prywatnemu adresowi IP swojej stacji roboczej. To nadaje mu nazwę wewnętrzną.
4. Skonfiguruj serwer DHCP, aby nadać adres tego serwera DNS innym urządzeniom uzyskującym dzierżawę.
5. Na programistycznej stacji roboczej użyj OpenSSL do wygenerowania par kluczy dla prywatnego urzędu certyfikacji i serwera WWW.
6. Korzystając z OpenSSL, wystaw certyfikat główny dla urzędu certyfikacji i certyfikat dla nazwy wewnętrznej serwera WWW.
7. Skonfiguruj protokół HTTPS na serwerze WWW na swojej stacji roboczej deweloperskiej przy użyciu tego certyfikatu.
8. Zainstaluj certyfikat główny urzędu certyfikacji jako zaufany certyfikat główny na wszystkich urządzeniach.
9. Na wszystkich urządzeniach uzyskaj dostęp do tej nazwy wewnętrznej.

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):

1. Kup domenę od rejestratora, który oferuje DNS z interfejsem API . Może to być bezpośrednio w TLD lub od jednego z dostawców dynamicznego DNS, który umieścił go na liście sufiksów publicznych. (Dostawcy dynamicznego DNS spoza PSL są niedopuszczalni ze względu na ograniczenia szybkości nałożone przez Let's Encrypt ).
2. W pliku strefy tej domeny wskaż Arekord na prywatny adres IP swojej stacji roboczej. Dzięki temu programistyczna stacja robocza ma nazwę FQDN.
3. Użyj Dehydrated , klienta ACME, który obsługuje dns-01wyzwanie, aby uzyskać certyfikat dla tej nazwy FQDN z urzędu certyfikacji Let's Encrypt.
4. Skonfiguruj protokół HTTPS na serwerze WWW na swojej stacji roboczej deweloperskiej przy użyciu tego certyfikatu.
5. Dostęp do tej nazwy na wszystkich urządzeniach.

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 ...

• Firefox: działał z poniższymi ustawieniami i bez nich.
• Chrome: bez dodawania adresów URL do białej listy i ponownego uruchamiania otrzymałem

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:

1. Wejdź na chrome: // flags / # unsafely-treat-insecure-origin-as-secure
2. Dodaj adresy URL, które chcesz umieścić na białej liście.
3. Uruchom ponownie Chrome

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

1. Otwórz narzędzia programistyczne
2. Otwórz ustawienia
3. Zaznacz „Włącz pracowników usług przez HTTP (gdy przybornik jest otwarty)”

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)