Параметри тестування службовців через HTTP


96

Я хочу протестувати службовців, але у мене налаштований віртуальний хост, і я, здається, не можу ввімкнути https на localhost.

Як я можу додати в білий список свою локальну віртуальну хост-адресу для тестування службовців, коли я намагаюся зареєструватися для службовця на localhost? Chrome каже, що https потрібен, щоб увімкнути службовця. Як я можу подолати це обмеження принаймні для місцевого тестування.

Відповіді:


140

Взагалі, вам потрібно обслуговувати як свою сторінку, так і сценарій службовця через 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 під час обслуговування робочої версії вашого сайту. Не просіть реальних користувачів проходити кроки ввімкнення цих прапорів!


спасибі Джефф спробує це відразу. безумовно, я використовую це лише для тестування .. потрібен відчайдушний обхідний час ... !! я знаю не ідеальну практику .. але безвихідні часи вимагають зневажливих заходів ... !! чи не могли б ви повернути мені мої зароблені 4 бали ... !! я
видалю

1
використовуючи працівника служби в localhost, але коли він намагався отримати файл sw.js із сервера, він показує net :: ERR_INSECURE_RESPONSE,
sp1rs

1
Дякую! Я оновив основний текст для читання devtools.serviceWorkers.testing.enabled.
Jeff Posnick

5
Для тих, хто мав проблеми з пошуком вище - відкрийте FF - інструменти розробника - налаштування зубчастого колеса - розширені налаштування - увімкніть sw over http. Тоді ви можете перейти до приблизно: налагодження # працівників за адресою url або tools - web dev - працівників служби на панелі інструментів. Пустіть працівника!
Sten Muchow

Відповідь @StenMuchow працює для мене у chrome mac та windows
Mohamed Hussain

51

Якщо ви хочете налагодити підключеного службовця служби мобільного пристрою для реального тестування поведінки прогресивного веб-додатка, параметри запуску 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 року не дуже зрозуміло читати це проста відповідь)


Виглядає багатообіцяюче, але у мене не вийшло. Просто каже: "Цей сайт недоступний" при спробі відвідати localhost на Android 5.0.2 після налаштування переадресації портів.
Джексон

Тобто вам не потрібен https на localhost? Чи буде SW працювати нормально?
Machado,

2
Це має бути прийнятою відповіддю, це працює нормально
Мікель

Швидко і просто! Не забудьте увімкнути та прийняти налагодження USB на телефоні та підключити його до ПК через USB. Дякую людино!
Marcos R

Але лише для http, якщо ви запитуєте ресурси через https, вони не будуть кешовані.
Legends

24

Я часто хочу налагодити та протестувати на реальному пристрої. Один із методів, який я придумав, включає маршрутизацію мережевого трафіку телефону через Чарльза Проксі під час локальної розробки. На відміну від усіх рішень для Chrome, це працює з будь-яким браузером на вашому телефоні.

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

4
я теж стикаюся з цією проблемою, велике спасибі. Тестувати мобільний телефон абсолютно неможливо без проксі. за цю публікацію потрібно більше голосів.
Phyo Arkar Lwin

1
@ chris-ruppel Насправді є спосіб зробити це без додаткового проксі-програмного забезпечення за допомогою Chrome Dev Tools при побудові переадресації портів віддалених пристроїв. Я додав докладну відповідь у цій темі.
Крістофер Леркен

"Тестувати мобільний телефон абсолютно неможливо;" але це незначний недогляд. Давайте аплодуватимемо людям, які визначили працівників сфери обслуговування ...
Джексон,

Кріс, ти можеш детальніше розповісти "1. Запусти Чарльза на моєму ноутбуці"? Можна встановити проксі Чарльза. У нього на сервері працює сервер localhost: 8080. Тоді що? Ви також кажете "зверніть увагу на IP / порт". Де?
Джексон,

1
@ChrisRuppel Я перейшов на ngrok.com : Безкоштовно, створює загальнодоступний HTTPS-сайт для мого місцевого додатку і працює як шарм! Перший запуск зайняв деякий час, поки він не підключився. Єдине, що я рекомендую, це переключити регіони, якщо ви не в США ( ngrok.com/docs#config-options , параметр "регіони").
Карстен Сільц,

11

У моєму випадку найпростішим способом перевірки 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


Працював як оберіг! Дякуємо за чудову рекомендацію!
Карстен Сільц

це теж допомагає, хоча у
мене

3

Як згадував Джефф у першій відповіді, вам не потрібні https на рівні localhost для тестування працівників служби. Службовці реєструватимуться і працюватимуть чудово, доки ви отримуєте доступ до домену localhost - без HTTPS.

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

Ось інструкції: https://pages.github.com/


1
Наступним запитанням було б питання щодо програмних рекомендацій: які веб-сервери для iOS та Android рекомендуються для тестування на мобільному пристрої за допомогою методу localhost?
Damian Yerrick

Я використовую сервер Erlang HTTP, але будь-який сервер повинен працювати. Я використовував до сервера HTTP 200 з Chrome, до якого ви можете отримати доступ із Google Marketplace.
Мігель Гуардо

3

Якщо ви хочете протестувати службовців на клієнтському пристрої, який не може запустити веб-сервер на localhost, загальний прийом такий:

  1. Дайте своєму серверу ім’я хосту.
  2. Дайте цьому імені хоста сертифікат.
  3. Змусьте IP-адреси довіряти CA, який видав цей сертифікат.

Але це простіше сказати, ніж зробити. У листопаді 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 видайте кореневий сертифікат для ЦС та сертифікат для внутрішнього імені веб-сервера.
  7. Налаштуйте HTTPS на веб-сервері на робочій станції розробника, використовуючи цей сертифікат.
  8. Встановіть кореневий сертифікат ЦС як надійний кореневий сертифікат на всіх пристроях.
  9. На всіх пристроях отримайте доступ до цього внутрішнього імені.

Якщо ви не можете додати кореневий сертифікат або керувати локальним DNS, наприклад, якщо ви плануєте тестувати на пристроях, що належать іншим (BYOD), або з більш заблокованими браузерами, які не дозволяють користувачам додавати надійні кореневі сертифікати, такі як основні відеоігрових консолей, вам знадобиться повністю кваліфіковане доменне ім’я (FQDN):

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

1

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

Я переважно використовую героку та netlify . це безкоштовно та просто у використанні.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.