Service worker chrome что это

Web-приложения в режиме offline. ServiceWorker и CacheStorage

О чём речь?

Всё чаще возникает задача научить frontend-приложение работать в автономном режиме. Это значит придать web-приложению свойство mobile- или desktop-программы — функционировать в отсутствии связи с Интернет, а также в случае отказа сервера.

Цель — оградить пользователя от проблем соединения на его устройстве. Как было бы обидно не сохранить созданные в google docs таблицы из-за потери wi-fi в ближайшем фастфуде!

Для этого нужно инициализировать приложение в браузере и затем закэшировать ресурсы, минимально необходимые для функционирования. После этого приложение возможно запустить из кэша в случае недоступности сервера.

Решение задачи заключается в следующем:

Теперь на арену выходит CacheStorage, с которым можно работать в ServiceWorker’е.

ServiceWorker

ServiceWorker — это новая технология, позволяющая запускать javascript-код в браузере в фоновом режиме — аналог сервисов (служб) в операционных системах. ServiceWorker запускается с web-ресурса и продолжает работать в браузере независимо от приложения, которое его инициализировало.

Часто цель применения ServiceWorker это получение push-уведомлений в браузере и контроль кэшируемых ресурсов, последнее как раз наш случай.

CacheStorage

CacheStorage представляет собой контейнер для хранения кэша сетевых ресурсов. Глобальный объект CacheStorage доступен по имени caches. Его составляющие это объекты типа Cache.

Cache — это именованное хранилище из пар: объект Request — объект Response. Для каждого закэшированного ресурса экземпляр Cache будет хранить request и response, созданные функцией fetch.

Как это выглядит на практике?

Следующим шагом пишем простой код ServiceWorker’а.

Важно иметь в виду, что serviceWorker никак не связан с глобальной областью видимости приложения, в котором был зарегистрирован, и вообще не имеет объекта window. В self у него находится объект типа ServiceWorkerGlobalScope, на котором устанавливаются обработчики событий.

После предпринятых действий и обновления страницы в chrome по адресу chrome://inspect/#service-workers можно увидеть примерно такую картину:

На данном скриншоте в браузере запущено в фоновом режиме три js-файла, первый из которых является кэширующим сервисом из данного примера.

Далее в коде serviceWorker’а на этапе инсталляции создаём первоначальный кэш из необходимых ресурсов.

Обратите внимание, все ссылки указаны относительно корня. Также среди кэшируемых ресурсов нет файла workerLoader.js, который регистрирует serviceWorker. Его кэшировать не желательно, т.к. в режиме offline приложение и без него будет работать. Но если срочно будет необходимо отключить serviceWorker, могут возникнуть проблемы. Пользователи вынуждены будут ждать пока serviceWorker обновится самостоятельно (посредством сравнения содержимого).

Далее добавляем в код serviceWorker’а обработчик события fetch. И на запрос ресурса выдаём его из кэша.

Но не всегда всё так просто. Допустим наши файлы статики поменялись на сервере. Усложним наш код. Проверим дату последнего обновления ресурса вытащив параметр last-modified из HTTP заголовков. И при необходимости подгрузим свежую версию файла и обновим кэш.

Примечание, для повторного запроса используются клоны request и response. Только один раз возможно отправить request и только один раз можно прочитать response. Из-за этого ограничения мы создаём копии этих объектов.

Подобным образом можно контролировать процесс кэширования. Теперь заметно явное преимущество перед appcache manifest в его декларативном стиле. Для разработчика открыта возможность оперировать HTTP заголовками, статус-кодами, содержимым и реализовать любую логику для отдельно взятых ресурсов.

Выводы

Лучшими материалами для написания этой статьи были:

Источник

Некоторые тонкости использования Service Workers

Предисловие

Сервис-воркеры (Service Workers, да простят меня читатели) сегодня являются полезным дополнением к основной функциональности сайта: тут и работа в оффлайне, и фоновая синхронизация данных, и модные пуш-уведомления.

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

Несколько сервис-воркеров на одном домене

У регистрации (registration) конкретного сервис-воркера есть такое понятие, как scope. Оно определяет, какие страницы на определённом домене будут подпадать под её контроль. При этом можно регистрировать несколько сервис-воркеров на одном домене, но с разными scope. Если попробовать зарегистрировать их с разными именами, но одним scope, то установленный позднее воркер будет «замещать» своего более раннего брата.

Кстати, для того, чтобы файл по указанному пути можно было установить в качестве сервис-воркера по пути выше (такое поведение запрещено по умолчанию, увеличивать путь можно, уменьшать — нет), то для этого можно использовать http-заголовок Service-Worker-Allowed.

Метод getRegistration() без параметров возвращает подходящую для текущей страницы регистрацию сервис-воркера, возможно, неактивную. Это также значит то, что по вложенному пути мы будем получать ту же самую регистрацию, если нет более подходящей. Это может приводить к неожиданностям, если ожидается работа нескольких сервис-воркеров на одном домене.

Рассмотрим пример: у нас есть установленный сервис-воркер со scope /. Пусть это будет новостной сайт и мы предоставляем оффлайновые версии текстов. Также есть панель управления по пути /admin/ со своим собственным сервис-воркером. Если второй сервис-воркер ещё не попытались установить, то getRegistaration() будет возвращать регистрацию первого сервис-воркера и это может приводить к ошибкам (например, мы будем слать нотификации из панели администратора в сервис-воркер, не готовый к ним вовсе).

getRegistration имеет опциональный параметр — scope. Если его указать, то метод вернёт регистрацию, наиболее подходящую (не обязательно равную) переданному scope. Тем самым мы можем отписываться от сервис-воркеров на вложенных страницах или получать вообще любые регистрации с текущего домена, нужно лишь знать подходящие scope.

А если мы не знаем все scope, то есть метод getRegistrations(), который просто возвращает все регистрации с текущего домена в виде массива. Требуется Firefox или Chrome 45+.

Связь между страницей и сервис-воркером

Возможность обмена данными между сервис-воркером и подчинённой страницей может привести довольно к оригинальным схемам работы. Например, можно сразу присылать данные из кеша, параллельно запрашивая новые; как только будут новые данные — положить их в кеш и прислать на страницу.

Пример на serviceworke.rs показывает простой способ общения с сервис-воркером:

Здесь controller — сервис-воркер, контролирующий страницу. В свежих браузерах (все версии Firefox и Chrome 51+) можно достаточно просто ответить на такой запрос:

В более старых версиях приходилось обходить все вкладки и находить нужную, а то и создавать руками MessageChannel. Также теперь у нас есть возможность отправлять сообщение вкладке из события fetch. Всё это описано в статье, разве что современное апи у нас уже есть.

Другой момент — хранение данных в сервис-воркере. Люди, уже опробовавшие сервис-воркеры, могли заметить, что LocalStorage там нет. Всё потому, что в сервис-воркерах был взят курс на полностью асинхронное апи (за исключением, пожалуй, importScripts). Но внутри всё ещё остаются доступны:

Или как-то так, но тогда нужно будет иметь в одном месте полный список возможных кешей.

Но при всём этом стоит помнить, что никто не гарантирует 100% сохранность данных в хранилищах. Браузер может автоматически чистить CacheStorage и indexedDB при нехватке места на диске, да и пользователь может сделать это сам.

Кроссдоменные запросы и прочее взаимодействие с другими доменами

С введением fetch ситуация могла показаться немного запутанной (там есть разные режимы запроса/ответа), а с сервис-воркерами всё становится в два раза сложнее: один fetch на стороне клиента, второй — на стороне сервис-воркера.

Самое простое понимание, к которому можно придти: «обмануть» CORS и получить доступ к контенту с другого домена без заголовков не получится. Важно разделять два вида использования: с доступом со стороны javascript и без него. Например, подменить одну картинку другой можно без проблем: достаточно указать в fetch сервис-воркера mode: ‘no-cors’ и не важно, какие там заголовки. Если не использовать ‘no-cors’, fetch будет ожидать CORS заголовки и в случае их отсутствия всё окончится ошибкой.

Если говорить более строго, то любой запрос (Request) со страницы имеет mode. Например, запрос картинки — ‘no-cors’, а запрос картинки с атрибутом crossOrigin (anonymous или use-credentials) — уже ‘cors’. Запросы через XMLHttpRequest всегда в режиме ‘cors’. А fetch позволяет задавать режим напрямую.

Ответ (Response) имеет свойство type. Запросы на текущий домен — ‘basic’. Иначе, если режим запроса — ‘cors’, то type ответа тоже будет ‘cors’, при наличии необходимых заголовков. Режим ответа ‘opaque’ можно получить на запрос в режиме ‘no-cors’, в нём нельзя получить доступ к каким-либо данным ответа.

Здесь описаны не все возможные виды режимов запросов, но этого должно быть достаточно для общего понимания. Больше информации можно почерпнуть из статьи с описанием fetch.

Теперь попробуем всё скомбинировать. Со страницы уходит запрос, его перехватывает сервис-воркер и делает свой fetch, получает ответ. До текущего момента ситуация разобрана, но теперь будет нюанс: при передаче ответа с типом ‘opaque’ в ответ на запрос страницы. который был сделан не с режимом ‘no-cors’, мы получим ошибку.

Помимо просто запросов, мы можем установить сервис-воркер на другой домен. Нет, мы не получим контроль за другой страницей через наш сервис-воркер — условия на сервис-воркер остаются теми же (сам скрипт должен быть на том же домене, на который регистрируется воркер). Для этого можно использовать iframe с нужного домена — разрешений от пользователя не требуется и iframe можно сделать просто невидимым.

Другая интересная возможность, которая сейчас находится в своей ранней версии — Foreign Fetch. Если обычный сервис-воркер контролирует запросы со страницы в своём scope (страница в scope, а не запросы), то foreign fetch позволяет контролировать запросы на свой домен. Допустим, обычное событие fetch будет срабатывать при запросе за библиотекой на CDN, а foreignFetch будет срабатывать при всех запросах за этой библиотекой на любых сайтах! Это любопытная возможность может быть использована, например, службами аналитики.

Тестирование

С написанием тестов на сервис-воркеры есть определённые сложности. Составление теста не так просто: если мы хотим проверить оффлайновый режим, то нужно как-то эмулиовать ошибки сети, если хотим проверить обновление — нужно подменять файл новым и тому подобное.

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

Есть стоящая статья на тему тестирования сервис-воркеров. В ней есть ссылки и на пару инструментов: sw-unit-test-sample и platinum-sw (элемент для Polymer, в нём есть также пара тестов). В статье также описан интересный приём: создание ифрейма для того, чтобы он контролировался тестируемым сервис-воркером. Вообще говоря, у элементов iframe и object есть другая особенность: запросы за ними и их содержимым идут в обход текущего сервис-воркера страницы, используя собственные сервис-воркеры.

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

Важный нюанс при работе автотестов — определение момента, когда сервис-воркер контролирует страницу и может перехватывать запросы. Простой navigator.serviceWorker.ready не всегда является верным решением — ready срабатывает в момент активации сервис воркера, но до того, как закончится выполнение clients.claim(). Более подробно описано здесь, как одно из решений — слушать событие controllerchange.

Обновление сервис-воркера

Есть несколько нюансов при обновлении сервис-воркеров, на которые стоит обратить внимание.

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

Другой нюанс: обновление срабатывает, только если сам скрипт сервис-воркера обновился, и определение этого происходит побайтово. Из этого следует, что обновление файлов, которые подключены через importScripts, не приведёт к обновлению самого сервис-воркера.

При обновлении часто добавляются в кеш из сети какие-то файлы. Но при этом работает браузерный кеш! Как и при вызовах fetch внутри сервис-воркера. Нужно либо быть уверенным, что файлы не поменялись (например, включать версию/хеш в название файла), либо загружать ресурсы в обход кеша. Чтобы загружать ресурсы в обход кеша, можно или руками звать fetch и потом добавлять ответ в кеш (не забывая проверять response.ok, например), или использовать опцию cache: ‘no-cache’ Request’а (пока работает только в Firefox Nightly). И то и то описано в статье Jake Archibald.

Также стоит упомянуть, что запрос за скриптом сервис-воркера при обновлении идёт в обход обработчика события fetch текущего сервис-воркера.

Источник

Использование Service Worker для создания ботнета

Если кратко: в этом посте мы рассмотрим один из множества способов запуска бесконечного выполнения кода Javascript в браузере с помощью Service Worker, а еще немного покритикуем саму технологию.

Пример вы найдете по этой ссылке. Закройте вкладку. Через несколько минут откройте DevTools/Application/ServiceWorker/Show All. Видите, код продолжает работать (хотя сейчас это может уже исправлено).

Веб-разработчики такого не ожидали: как тег изображения может запустить выполнение кода JS? Каким образом JS может выполняться непрерывно? Разве так можно?

Service Worker — это слишком сложно

Чтобы повысить популярность «прогрессивных» веб-приложений, команда Chrome создала Service Worker, не спрашивая у вас разрешения. На практике это новое «продвинутое» решение используется только чтобы показывать всплывающее push-уведомление (Конечно, полезность Service Worker-ов на этом не ограничивается, с их помощью реализуются, например, offline-режим и backsync, – прим. переводчика). Если вы не верите мне на слово, откройте свои зарегистрированные Service Worker и изучите их содержимое.

Даже это будет сделать не так-то просто: сотни строк кода, зависимость от FCM и т. д. (FCM = Firebase Cloud Messaging, но его использование не является обязательным в данном случае, – прим. переводчика). Разместите sw.js на сервере, зарегистрируйте worker на стороне клиента, подождите получения Promise, затем выполните serviceWorkerRegistration.pushManager.getSubscription(), запросите конечную точку и registration_id и сохраните их на сервере.

Так реализовал бы я:

По моему скромному мнению, Service Worker — это прекрасный ответ на несуществующий вопрос. Научиться использовать это решение гораздо сложнее, чем Appcache (AppCache, в свою очередь, считается устаревшей технологией со своими минусами, – прим. переводчика ), к тому же оно менее надежно.

Как обеспечить долговременную работу

Service Worker отключается через 60 секунд после того, как получает последнее событие, например, onmessage, onfetch, onforeignfetch и т. д.

1. Отправка сообщений самому себе.

1. Два worker отправляют друг другу запросы ForeignFetch. Чтобы использовать ForeignFetch, вам понадобится получить токен Origin Trial — полностью автоматизированный процесс, который не требует проверки или подтверждения и позволяет злоумышленнику применять новые экспериментальные технологии на реальных пользователях без их согласия.

2. Catworker отправляет cat.gif запрос fetch, в результате регистрируется новый worker с другой областью работы (это называется регистрация по ссылке). Процесс повторяется каждые 55 секунд.

Как это могут использовать злоумышленники?

Прямо сейчас у злоумышленников есть три варианта атаки вашего браузера:

Сейчас этому классу ошибок уделяют недостаточно внимания. Тикеты публичны (1, 2, 3) и получают минимальный приоритет.

Помимо всего этого, подход Origin Trial не безупречен: кто угодно может получить токен, любой может воспользоваться экспериментальной функцией в своих целях. Нужна возможность включать и отключать Service Worker по желанию.

Я убежден, что нужно добавить флажок для отключения Service Worker. Лично мне эта технология пользы не приносит. (Вы читали документацию Cache? Это же как китайская грамота.) Новые функции поступают в эксплуатацию без должной проверки, так что нельзя быть уверенным в Same Origin Policy и других важных концепций безопасности… Вот еще несколько описаний несерьезных уязвимостей: FF, JSONP+XSS=takeover, атака доменов изолированной программной среды (Sandbox).

Источник

Service Worker API

Service worker фактически выполняет роль прокси-сервера, находящегося между веб-приложением и браузером, а также сетью (если доступна). Он позволяет (кроме прочего) описывать корректное поведение веб-приложения в режиме офлайн, перехватывать запросы сети и принимать соответствующие меры, основываясь на доступности сети, и обновлять данные, находящиеся на сервере при доступе к нему. Также они имеют доступ к push-уведомлениям и API для фоновой синхронизации.

Концепция и использование Service Worker

Service worker — это событийно-управляемый worker, регистрируемый на уровне источника и пути. Он представляет собой JavaScript-файл, который может контролировать веб-страницу/сайт, с которым он ассоциируется, перехватывать и модифицировать запросы навигации и ресурсов, очень гибко кешировать ресурсы, для того чтобы предоставить вам полный контроль над тем, как приложение ведёт себя в определённых ситуациях (например, когда сеть не доступна).

Service worker запускается в контексте воркеров, поэтому он не имеет доступа к DOM и работает в потоке отдельном от основного потока JavaScript, управляющего вашим приложением, а следовательно — не блокирует его. Он призван быть полностью асинхронным; как следствие, синхронные API, такие как XHR и localStorage, в Service Worker’е использовать нельзя.

Из соображений безопасности service worker’ы работают только по HTTPS (либо, в целях разработки, на localhost ). Давать сторонним людям возможность изменять сетевые запросы крайне опасно. Кроме того, Service Worker API недоступен в режиме приватного просмотра браузера Firefox.

Примечание: Service Worker’ы выигрывают у предыдущих решений, таких как AppCache, потому что не делают предположений о том, что вы пытаетесь сделать, и не ломаются, в случаях если их предположения не оказываются верными; вы имеете полный контроль над всем.

Примечание: Service worker’ы широко используют промисы (Promises). В общем случае они будут ждать ответа, после которого вернутся с успешным или неудачным завершением. Архитектура на промисах для этого подходит идеально.

Регистрация

Загрузка, установка и активация

Service Worker будет следовать следующему жизненному циклу:

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

Установка производится в случае если загружаемый файл признается новым — либо отличным от уже установленного service worker (определяется через побайтовое сравнение), либо первым устанавливаемым service воркером для этой страницы/сайта.

Если это первый раз, когда service worker оказался доступен, будет проведена установка, а после успешного её завершения — активация.

Вы можете подписаться на InstallEvent (en-US) ; для того чтобы подготовить ваш service worker к использованию, к примеру, чтобы создать кеш при помощи встроенного API хранилища и разместить внутри него данные, которые вам необходимы в вашем приложении для работы офлайн.

Для полного руководства по созданию рабочего примера читайте Использование Service Worker.

Другие варианты использования

Service worker’ы также предназначены для таких вещей, как:

В будущем service worker’ы будут способны на многие другие полезные вещи для веб-платформ, приближая их к нативным приложениям. Примечательно, что другие спецификации могут и будут использовать контекст service worker, к примеру для:

Интерфейс

SyncEvent представляет синхронное действие, которое отправляется ServiceWorkerGlobalScope (en-US) ServiceWorker.

SyncManager (en-US) Обеспечивает интерфейс регистрации и перечисления синхронных регистрации. WindowClient Представляет область видимости клиентского service worker’а, представленного в виде документа в контакте браузера, контролируемого активным воркером. Это особый тип объекта Client (en-US) с некоторыми дополнительными методами и свойствами.

Спецификации (характеристики)

Совместимость

Таблица совместимости

[1] Service workers (и Push) были отключены в Firefox 45 Extended Support Release (ESR.)

Источник

Service Workers

В этой статье я хотел бы поговорить о Service Workers (SW). SW позволяют нам сделать наше приложение готовым к работе в автономном режиме, чтобы оно работало, даже если у нас нет подключения к Интернету. Они также позволяют нам использовать множество других расширенных функций, таких как push-уведомления или фоновая синхронизация. SW продолжает работать даже после закрытия браузера, то есть Service Workers продолжают работать. Это фоновый процесс. Итак, давайте зарегистрируем нашего первого Service Worker’a.

(В этой статье я реализую функциональность, связанную с SW, на простом JS, поскольку код написан на простом JS, мы можем интегрировать в любые JS-фреймворки, такие как Angular, React или Vue)

В качестве первого шага добавим файл sw.js в корневую папку проекта. В app.js мы должны проверить, доступен ли SW в навигаторе, то есть поддерживаются ли SW данным браузером. Теперь, когда мы знаем, что SW доступны, мы можем выполнить метод navigator.serviceWorker.register (), указывая путь к файлу, в котором находится наш SW, чтобы его зарегистрировать. Этот метод фактически возвращает Promise. Итак, чтобы получить информацию, как только это будет сделано, мы можем присоединиться к нему.

Поскольку мы зарегистрировали нашего первого SW, давайте добавим наш первый прослушиватель событий. Как я уже сказал, SW работают в фоновом режиме. Но я не упомянул одну вещь, что все они связаны с обработкой событий. Чтобы прикрепить слушателей событий к SW, мы, прежде всего, должны обратиться к нему с помощью ключевого слова self, что в основном означает «предоставь мне доступ к SW», а затем мы можем выполнить метод addEventListener (). SW надают доступ к специальному набору событий, например, к событию установки, которое запускается, когда браузер устанавливает Service Worker’a. Здесь мы выполняем функцию и получаем объект события, который автоматически передается в функцию браузером, и этот объект предоставляет нам информацию о событии установки. Как мы видим, наш Service Worker успешно установлен.

Теперь посмотрим, действительно ли эти файлы загружены в кеш-память.

Выражение event.respondWith () позволяет нам перезаписывать данные, которые отправляются обратно. Вы можете думать о Service Worker’е как о сетевом прокси, по крайней мере, если мы используем здесь событие fetch. Таким образом, каждый исходящий запрос на выборку проходит через Service Worker, как и каждый ответ. То есть, если мы ничего не делаем, ответ просто не передается. Выражение cashes.match () позволяет нам проверить, кэширован ли уже данный запрос. Если это так, он вернет кешированный ответ. Мы не делаем сетевой запрос, мы перехватываем запрос и не выдаем новый, вместо этого мы просто смотрим на то, что мы хотели запросить, и видим, есть ли оно в кеше и если есть, мы возвращаем его обратно. С другой стороны, если мы не находим его в кеше, мы хотим вернуть запрос на выборку там, где мы обращаемся или где мы просто продолжаем исходный запрос, поэтому вертаем fetch (event.request). После всех этих изменений мы наконец можем использовать наше веб-приложение в автономном режиме.

Как видите, наше веб-приложение содержит диаграмму с некоторыми статическими данными, и при нажатии кнопки «ПОЛУЧИТЬ ДАННЫЕ» ничего не происходит. Теперь я хочу сделать так, чтобы нажав эту кнопку, мы получили некоторые статистические данные, отобразили их на диаграмме и сохранили эти данные в кеше. Таким образом, мы реализуем динамическое кеширование. Итак, приступим. Допустим, у нас есть эндпоинт, который возвращает статистические данные о том, сколько пользователей посетили наш сайт. Итак, теперь мы должны взять эти данные и отобразить их на графике.

Как и раньше, я добавлю решение, а затем объясню, как оно работает.

Сначала нам нужно проверить тег события. Затем я использую event.waitUntil (), как и раньше, это просто позволяет мне убедиться, что событие не завершилось преждевременно. Затем мы получаем данные, которые хранятся в indexedDB (используя вспомогательную функцию из utility.js), перебираем их, отправляем post запрос для каждого из сохраняемых фрагментов данных, а затем удаляем их из indexedDB, если мы успешно отправили их на сервер. Вот и все. Давайте теперь попробуем это. Чтобы проверить эту функциональность, мы должны перейти в автономный режим в нашем браузере, нажать кнопку «POST DATA» и затем снова выйти в онлайн.

После нажатия кнопки «POST DATA», когда мы не в сети, ничего не происходит, но когда подключение восстанавливается, мы видим, что синхронизация была выполнена.

И чтобы подтвердить, что данные действительно были отправлены на сервер, нам сначала нужно удалить наш запрос на получение из динамического кеша и нажать кнопку «ПОЛУЧИТЬ ДАННЫЕ».

Источник