Можно ли запретить обновления на PWA?

Question

[accountnujen]

Есть PWA. Приложение заметок. Исходный код открыт. Данные заметок хранятся на устройстве пользователя.
Возможно ли сделать так, чтобы в случае если я (разработчик) изменю код - у пользователей всё равно открывалась кэшированная версия и я не мог насильно обновить PWA?

Я попытался закешировать всё, но на данный момент при открытии PWA сразу идёт get запрос на service.js, который возвращает ему 304 (данные не изменились). Сейчас я могу просто переписать его и насильно обновить приложение у пользователя, добавив скрипт, который отправит мне на сервер заметки пользователя. Для обновления ему нужно просто закрыть приложение и открыть снова. Мне нужно каким-то образом гарантировать, что без ведома пользователя я не могу ничего сделать. Есть ли способы?

Answer 1

[rPman]

Штатно - нет.

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

Пользователь может разработать расширение браузера, через который будет работать PWA (на android это будет проблематично, но вроде firefox можно сделать тем что поддерживает webview а через него уже будет работать PWA но надо изучать вопрос), и в этом расширении блокировать запросы и соответственно обновление (не подмена, поэтому нужно смотреть принципиальную возможность так сделать, а то после блокировки приложение может думать что произошла ошибка и соответственно реагировать). Как минимум с гарантией можно отслеживать изменения файлов и выдавать предупреждение - типа 'все, приложение обновилось, назад пути нет'.

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

И конечно модификация самого браузера, тут возможно любое поведение.

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

Comments

[accountnujen]

я снова возвращаюсь к этой проблеме.

А можно ли симулировать service.js? Чтобы он генерировался виртуально? Когда после регистрации симмулированным файлом PWA обратится к service.js - оно получит ошибку 404 (которая меня как раз устраивает) и продолжит работать в offline режиме. Если можно подстроить и service.js, чтобы он не 404 отдавал, а что-то другое - это было бы ещё лучше.

Вот это мы можем сломать?

if ('serviceWorker' in navigator) {
    window.addEventListener('load', () => {
        navigator.serviceWorker.register('/service.js');
    });
}

Я также обращаюсь к тебе, Aetae! Здравствуй! Нужна консультация!

[Aetae]

accountnujen, всё грустно с этим.

А. ServiseWorker'ом может быть только конкретный url с того же origin. Никаких виртуальных файлов, никаких файлов с другого, более надёжного, домена.
Б. Браузеры по спеке всегда лезут проверять его обновление.

Так что если есть опасность, что сервак захватят, то "нормальное" решение тут только одно: не использовать ServiceWorker(и соответственно PWA). Руками всё кэшировать в какой-нить indexedDB и костылить.

Вот это мы можем сломать?

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

P.S. Ну разве что что-то стрёмное городить:
1. Грузить весь front-end сайта по "неподбираемой"(напр с uuid) url на "надёжный" сайт типа гугла (который точно не будет анализировать 404 запросы).
2. Просить юзаера установить PWA оттуда
3. После установки удалять всё оттуда и забывать url.