Варианты тестирования сервис-воркеров через HTTP

Я хочу протестировать сервис-воркеров, но у меня настроен виртуальный хост, и я не могу включить https на localhost.

Как я могу внести свой URL-адрес локального виртуального хоста в белый список для тестирования сервис-воркеров всякий раз, когда я пытаюсь зарегистрироваться для сервис-воркера на локальном хосте? Chrome говорит, что https необходим для включения сервис-воркера. Как обойти это ограничение хотя бы для локального тестирования.

В общем, вам необходимо обслуживать как свою страницу, так и скрипт сервис-воркера через HTTPS, чтобы использовать сервис-воркеры. Обоснование описано в разделе «Предпочитать безопасное происхождение мощным новым функциям» .

Существует исключение из требования HTTPS для облегчения локальной разработки: если вы обращаетесь к своей странице и скрипту сервис-воркера через http://localhost[:port]или через http://127.x.y.z[:port], тогда сервис-воркеры должны быть включены без каких-либо дополнительных действий.

В последних версиях Chrome вы можете обойти это требование во время локальной разработки chrome://flags/#unsafely-treat-insecure-origin-as-secure, как описано в этом ответе .

Firefox предлагает аналогичные функции через devtools.serviceWorkers.testing.enabledнастройку.

Обратите внимание, что эта функция предназначена только для облегчения тестирования, которое иначе было бы невозможно, и вы всегда должны планировать использование HTTPS при обслуживании производственной версии вашего сайта. Не просите реальных пользователей пройти этапы включения этих флагов!

Если вы хотите отладить сервис-воркера подключенного мобильного устройства для реального тестирования поведения прогрессивного веб-приложения, параметры запуска ssl chrome не помогут, и вам определенно не нужно покупать сертификаты.

@ chris-ruppel упомянул об установке прокси-программного обеспечения, но на самом деле есть более простой способ использовать переадресацию портов :

Предполагая, что вы подключаетесь и отлаживаете свое устройство с помощью Chrome:

• В Chrome Dev Tools «Удаленные устройства» откройте «Настройки» и добавьте правило «Перенаправление портов» .
• Если ваша установка localhost работает на localhost: 80,
• просто добавьте правило «Порт устройства 8080» (может быть любой непривилегированный порт> 1024)
• и локальный адрес localhost: 80 (или mytestserver.sometestdomainwithoutssl.company:8181 или что-то еще)

После этого вы можете вызвать URL-адрес « http: // localhost: 8080 » на своем мобильном устройстве, и ему ответит «localhost: 80» на вашем реальном ПК / тестовом сервере . Отлично работает с обслуживающими работниками, как если бы это был локальный компьютер, работающий на вашем мобильном телефоне.

Также работает для переадресации нескольких портов и разных целевых доменов, если вы не забываете использовать непривилегированные порты на своем мобильном устройстве. Смотрите скриншот:

Источником этой информации является документация по удаленным устройствам Google: https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server (но по состоянию на апрель 2017 года не очень понятно, чтобы прочитать это простой ответ из этого)

Я часто хочу отлаживать и тестировать на реальном устройстве. Один метод, который я придумал, заключается в маршрутизации сетевого трафика телефона через Charles Proxy во время локальной разработки. В отличие от всех решений для Chrome, это работает с любым браузером на вашем телефоне.

1. Запустите Charles на моем ноутбуке (который также обслуживает мой веб-сайт вместе с Service Worker). После запуска Charles запишите IP / порт для шага 2.
2. Настройте мобильное устройство на использование моего ноутбука в качестве прокси.
   • Для Android просто нажмите и удерживайте свой Wi-Fi в настройках> Изменить сеть > Дополнительные настройки > Прокси . Используйте Вручную, чтобы установить IP / порт.
   • Для iOS щелкните значок (i)> раздел HTTP-прокси . Выберите « Вручную» , затем установите IP / порт.
3. Посещение localhostмоего мобильного устройства теперь позволяет зарегистрировать и протестировать Service Worker.

В моем случае самый простой способ проверить pwa - использовать ngrok. https://ngrok.com/download авторизуйтесь, получите токен ur и установите его!

При запуске ./ngrok http {your server port}убедитесь, что вы используете https, который будет отображаться в терминале после выполнения этой команды выше.

Вы также можете использовать https://surge.sh , он предназначен для размещения статической веб-страницы, если вы посетите здесь: https://surge.sh/help/securing-your-custom-domain-with-ssl сможет посмотреть, как настроить сертификат ssl

Если вы хотите протестировать сервис-воркеров на клиентском устройстве, которое не может запустить веб-сервер на локальном хосте, общий метод будет следующим:

1. Дайте вашему серверу имя хоста.
2. Дайте этому имени хоста сертификат.
3. Сделайте IP-адреса доверяющими центру сертификации, выдавшему этот сертификат.

Но легче сказать, чем сделать. В ноябре 2016 года в AMA на Reddit представитель Let's Encrypt признал, что HTTPS в частной локальной сети «является действительно сложным вопросом, и я думаю, что пока никто не дал удовлетворительного ответа».

Обычные способы дать вашему компьютеру имя хоста включают в себя предоставление ему стабильного внутреннего IP-адреса, который не меняется ежедневно или каждый раз, когда вы выключаете и выключаете свое устройство Интернет-шлюза. Вам необходимо настроить DHCP-сервер в вашей сети, обычно это в вашем шлюзе, чтобы настроить «резервирование», которое связывает конкретный частный адрес (обычно внутри 10/8или 192.168/16) с MAC-адресом Ethernet-карты вашей рабочей станции разработки. Для этого прочтите руководство к вашему шлюзу.

Теперь, когда ваша рабочая станция разработки имеет стабильный IP-адрес, нужно время / деньги. Если вы хотите изучить расширенное использование DNS и OpenSSL и установить корневой сертификат на все устройства, с которыми вы планируете тестировать:

1. Запустите внутренний DNS-сервер в своей сети. Это может быть ваш шлюз или ваша рабочая станция разработчика.
2. Настройте свой DNS-сервер так, чтобы он был авторитетным для некоторых надуманных TLD и рекурсивным для других TLD.
3. Дайте стабильное имя частному IP-адресу вашей рабочей станции разработки. Это дает ему внутреннее имя.
4. Настройте свой DHCP-сервер, чтобы он передавал адрес этого DNS-сервера другим устройствам, получающим аренду.
5. На своей рабочей станции разработчика используйте OpenSSL для создания пар ключей для частного центра сертификации и веб-сервера.
6. Используя OpenSSL, выдайте корневой сертификат для CA и сертификат для внутреннего имени веб-сервера.
7. Настройте HTTPS на веб-сервере на рабочей станции разработчика с помощью этого сертификата.
8. Установите корневой сертификат ЦС в качестве доверенного корневого сертификата на всех устройствах.
9. На всех устройствах получите доступ к этому внутреннему имени.

Если вы не можете добавить корневой сертификат или управлять локальным DNS, например, если вы планируете тестировать с устройствами, принадлежащими другим лицам (BYOD), или с более заблокированными браузерами, которые не позволяют пользователям добавлять доверенные корневые сертификаты, например, в основных для игровых приставок вам потребуется полное доменное имя (FQDN):

1. Купите домен у регистратора, который предлагает DNS с API . Это может быть непосредственно в TLD или от одного из поставщиков динамических DNS, который внес его в список общедоступных суффиксов. (Не-PSL-провайдеры динамических DNS неприемлемы из-за ограничений скорости, установленных Let's Encrypt .)
2. В файле зоны этого домена укажите Aзапись на частный IP-адрес рабочей станции разработчика. Это дает вашей рабочей станции разработки полное доменное имя.
3. Используйте Dehydrated , клиент ACME, который поддерживает эту dns-01задачу, чтобы получить сертификат для этого полного доменного имени от центра сертификации Let's Encrypt.
4. Настройте HTTPS на веб-сервере на рабочей станции разработчика с помощью этого сертификата.
5. На всех устройствах получите доступ к этому имени.

Как Джефф упомянул в первом ответе, вам не нужен https на уровне localhost для тестирования Service Workers. Сервисные работники будут регистрироваться и работать нормально, пока вы получаете доступ к домену localhost - без HTTPS.

После того, как ваше приложение протестировано на localhost и вы захотите увидеть, как оно работает с https на самом деле, самым простым подходом будет загрузить ваше приложение на GitHub. Вы можете создать публичный домен бесплатно (и с HTTPS!).

Вот инструкции: https://pages.github.com/

Я думаю, что самый простой способ протестировать сервис-воркера - это найти бесплатного хостинг-провайдера. В настоящее время существует множество сайтов, предоставляющих бесплатный хостинг. вы можете легко разместить свое приложение на этих бесплатных серверах.

Я в основном использую heroku и netlify . это бесплатно и легко использовать.

Я использовал ngrok для туннелирования локального IP (на самом деле это не так, потому что он находится в Google Colab) к общедоступному.

Зайдя в консоль ngrok, я вижу все созданные туннели. Я создал только один туннель для localhost: port, но здесь их два, один для HTTP и другой для HTTPS (разве это не хорошо?).

Если я перейду на https-адрес своего веб-приложения, на консоли я вижу

Но если я перейду на http-адрес, на консоли я получаю

В: Можете ли вы работать с сервис-воркерами, которым нужны HTTP-соединения через туннели на удаленную машину?

A: Очевидно да!

Код, стоящий за этой регистрацией (важно знать, где она не удалась):

// 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!');
    });
};

И что еще более усложняет, мое веб-приложение, использующее Service Workers, работает внутри Colab ( Google Colab ). Веб-приложение работает на Node.js внутри Colab.

Если вы работаете с localhost, вам должно быть проще, потому что требование https не применяется при подключении к localhost (согласно теории). [A] и [B]

Это не то же самое, что браузер будет хорошо работать с вашим приложением только потому, что он работает на localhost.

Примечание: мой эксперимент выше ..

• Firefox: работал с указанными ниже настройками и без них.
• Chrome: без добавления URL-адресов в белый список и перезапуска я получил

При переходе в веб-приложение https я получил:

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)

При переходе в веб-приложение http я получил:

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.

Если вы не на локальном хосте и не можете использовать https, вам может потребоваться изменить эти настройки в своем браузере.

Некоторые люди уже объяснили это, но здесь это снова.

Хром:

1. Перейдите к chrome: // flags / # unsafely-Treat-insecure-origin-as-secure
2. Добавьте URL-адреса, которые хотите добавить в белый список.
3. Перезапустить хром

Обратите внимание, что это перезапустит все окна Chrome. Это не решение для меня, потому что мои туннели меняют имя каждый раз, когда они создаются, и я не могу каждый раз перезапускать кучу окон.

Firefox / Waterfox

1. Открыть инструменты разработчика
2. Открыть настройки
3. Отметьте «Включить сервис-воркеров через HTTP (при открытой панели инструментов)»

Firefox / Waterfox Вероятно, вам не нужно вносить изменения, указанные ниже, но я сделал (мой браузер может быть немного устаревшим). Больше информации здесь .

В about: config

Я включил

dom.serviceWorkers.testing.enabled
dom.serviceWorkers.enabled

Я настоятельно рекомендую посмотреть этот https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers и связанные с ним страницы на том же сайте.

Если кого-то интересует настройка ngrok, это очень просто (версия на Python).

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