HTTP를 통한 서비스 워커 테스트 옵션

HTTP를 통한 서비스 워커 테스트 옵션

---

서비스 워커를 테스트하고 싶지만 가상 호스트 설정이 있고 localhost에서 https를 활성화 할 수없는 것 같습니다.

로컬 호스트에서 서비스 워커를 등록하려고 할 때마다 서비스 워커를 테스트하기 위해 로컬 가상 호스트 URL을 허용 목록에 추가하려면 어떻게해야합니까? Chrome은 서비스 워커를 사용하려면 https가 필요하다고 말합니다. 최소한 로컬 테스트를 위해이 제한을 어떻게 극복 할 수 있습니까?

---

일반적으로 서비스 워커를 사용하려면 HTTPS를 통해 페이지와 서비스 워커 스크립트를 모두 제공해야합니다. 그 이유는 강력한 새 기능을 위해 안전한 출처 선호에 설명되어 있습니다.

당신이를 통해 페이지 및 서비스 노동자 스크립트에 액세스하는 경우 :이 지역의 개발을 촉진하기 위해 자리에 HTTPS 요구 사항에 대한 예외입니다 http://localhost[:port], 또는를 통해 http://127.x.y.z[:port], 다음 서비스 노동자는 어떤 추가 작업없이 사용하도록 설정해야합니다.

어떤 이유로 든 localhost또는 이외의 호스트 이름을 통해 로컬 웹 서버에 액세스해야 127.x.y.z하거나 HTTPS를 지원하지 않는 원격 웹 서버에서 테스트 해야하는 경우 사용할 수있는 수동 해결 방법이 있습니다. 명령 줄을 통해 Chrome을 시작하고 --user-data-dir및 --unsafely-treat-insecure-origin-as-secure플래그 를 모두 사용합니다 .

이 버그 에는 Chrome을 실행하는 방법 의 전체 예 를 포함하여 자세한 내용 이 있습니다.

Firefox 는devtools.serviceWorkers.testing.enabled 설정을 통해 유사한 기능을 제공 합니다.

이 기능이되어 있습니다 만 그 그렇지 않으면 일어날 수 없을 것입니다 테스트를 용이하게하기위한 것, 그리고 당신은 항상 당신의 위치의 생산 버전을 제공 할 때 HTTPS를 사용하여 계획해야합니다. 실제 사용자에게 해당 플래그를 활성화하는 단계를 거치도록 요청하지 마십시오!

---

프로그레시브 웹 앱의 실제 동작 테스트를 위해 플러그인 된 모바일 장치의 서비스 워커 를 디버깅 하려는 경우 SSL 크롬 시작 옵션이 도움이되지 않으며 인증서를 구매할 필요가 없습니다.

@ chris-ruppel은 프록시 소프트웨어 설치를 언급했지만 실제로 포트 포워딩을 사용 하는 더 쉬운 방법이 있습니다 .

Chrome을 사용하여 기기를 연결하고 디버그한다고 가정합니다.

• 에서 크롬 개발 도구 "원격 장치" 개방 "설정" 및 추가 "포트 포워딩" 규칙을.
• localhost 설정이 localhost : 80에서 실행중인 경우
• "Device port 8080" 규칙을 추가하기 만하면됩니다 (1024보다 큰 권한이없는 포트 일 수 있음).
• 및 로컬 주소 "localhost : 80"(또는 mytestserver.sometestdomainwithoutssl.company:8181 또는 기타)

그런 다음 모바일 장치 에서 URL " http : // localhost : 8080 "을 호출 할 수 있으며 실제 PC / 테스트 서버 의 "localhost : 80"에 의해 응답됩니다 . 마치 모바일에서 실행되는 로컬 컴퓨터 인 것처럼 서비스 작업자와 완벽하게 작동합니다.

모바일 장치에서 권한이없는 포트를 사용하는 것을 기억하는 한 다중 포트 전달 및 다른 대상 도메인에서도 작동합니다. 스크린 샷보기 :

이 정보의 출처는 Google 원격 장치 문서입니다 : https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (그러나 2017 년 4 월 현재이 내용을 읽는 것이 명확하지 않습니다. 간단한 대답)

---

나는 종종 실제 장치에서 디버그하고 테스트하고 싶습니다. 내가 생각 해낸 한 가지 방법은 로컬 개발 중에 Charles Proxy를 통해 전화의 네트워크 트래픽을 라우팅하는 것 입니다. 모든 Chrome 전용 솔루션과 달리 이것은 휴대 전화의 모든 브라우저에서 작동합니다.

1. 내 랩톱에서 Charles를 실행합니다 (서비스 워커와 함께 내 웹 사이트를 제공함). Charles가 실행되면 2 단계의 IP / 포트를 기록해 둡니다.
2. Configure the mobile device to use my laptop as a proxy.
   • For Android just tap and hold on your WiFi in settings > Modify network > Advanced Settings > Proxy. Use Manual to set the IP/port.
   • For iOS click the (i) icon > HTTP Proxy section. Select Manual, then set the IP/port.
3. Visiting localhost on my mobile device now allows the Service Worker to be registered and tested.

---

The easiest way to test pwa, in my case, was using ngrok. https://ngrok.com/download log in, get ur token and set it!

When you run ./ngrok http {your server port} make sure that you use https which will be shown in the terminal after you run this command above.

---

You could use https://surge.sh too, it is for host a static webpage, if you visit here: https://surge.sh/help/securing-your-custom-domain-with-ssl will be able to see how to set up a ssl certificate

---

As Jeff mentioned in the first response, you do not need https at the localhost level to test Service Workers. Service workers will register and work just fine as long as you access the localhost domain -- without HTTPS.

Once you have your application tested on localhost and you want to see how it works with https for real, the simplest approach would be to upload your app to GitHub. You can create a public domain for free (and with HTTPS!).

Here are the instructions: https://pages.github.com/

---

If you want to test service workers on a client device that cannot run a web server on localhost, the general technique is as follows:

1. Give your server a hostname.
2. Give this hostname a certificate.
3. Make IPs trust the CA that issued this certificate.

But this is easier said than done. In a November 2016 AMA on Reddit, a Let's Encrypt representative acknowledged that HTTPS on a private LAN "is a really tough question, and I think no one has come up with a satisfactory answer so far."

Common ways to give your computer a hostname involve giving it a stable internal IP address, not one that changes daily or every time you power-cycle your Internet gateway appliance. You'll need to configure the DHCP server on your network, usually that in your gateway, to set up a "reservation" that associates a particular private address (usualy within 10/8 or 192.168/16) with the MAC address of your development workstation's Ethernet card. For this, read the manual of your gateway.

Now that your development workstation has a stable IP address, there's a time/money tradeoff. If you're willing to learn advanced DNS and OpenSSL usage and install a root certificate on all devices with which you plan to test:

1. Run an internal DNS server on your network. This could be on your gateway or on your development workstation.
2. Configure your DNS server to be authoritative for some made-up TLD and recursive for other TLDs.
3. Give a stable name to your development workstation's private IP address. This gives it an internal name.
4. Configure your DHCP server to give the address of this DNS server to other devices obtaining leases.
5. On your development workstation, use OpenSSL to generate keypairs for a private certificate authority and the web server.
6. Using OpenSSL, issue a root certificate for the CA and a certificate for the web server's internal name.
7. Configure HTTPS in the web server on your development workstation using this certificate.
8. Install the CA's root certificate as a trusted root certificate on all devices.
9. On all devices, access this internal name.

If you cannot add a root certificate or control local DNS, such as if you plan to test with devices owned by others (BYOD) or with more locked-down browsers that do not allow users to add trusted root certificates, such as those in major video game consoles, you'll need a fully-qualified domain name (FQDN):

1. Buy a domain from a registrar that offers DNS with an API. This could be directly within a TLD or from one of the dynamic DNS providers that has made it onto the Public Suffix List. (Non-PSL dynamic DNS providers are unacceptable because of rate limits imposed by Let's Encrypt.)
2. In this domain's zone file, point an A record at your development workstation's private IP address. This gives your development workstation a FQDN.
3. Use Dehydrated, an ACME client that supports the dns-01 challenge, to obtain a certificate for this FQDN from the Let's Encrypt certificate authority.
4. Configure HTTPS in the web server on your development workstation using this certificate.
5. On all devices, access this name.

---

I think the easiest way to test service worker is to find a free hosting provider. nowadays, there many sites that provide free hosting. you can easily host your app on this free servers.

I mostly use heroku and netlify. this are free and easy to use.

참고 URL : https://stackoverflow.com/questions/34160509/options-for-testing-service-workers-via-http