Комментарии 18
Вот не люблю я не свободное ПО. Поэтому устанавливаю его только как PWA, в безопасном броузерном сэндбоксе. Чего и вам советую.
Кстати обратите внимание на 2 версии VSCode (личная и рабочая) установленных тоже как вэб приложения. Это работает в докере и локальном браузере, избегая загрузки электрона.
Ок, вопрос: локальная сеть, локальный вебсервер без всякого выхода в Интернет, на нем сайт, который неплохо бы было установить как PWA на локальные же планшеты (только локальная сеть, без выхода в интернет).
Но оно хочет https, то есть сертификаты, "соответствующие сайту".
Сделать самоподписанный не проблема - проблема чтобы планшетный браузер его принял.
Вот как это сделать?
Обходной путь с подменой домена есть, но как-то это всё через пень-колоду.
Так а что мешает использовать домен открытого типа, получать через условный Route53 авторизацию LE и подкидывать сайту? Это не прям жуткая проблема, хоть и доставляет некоторые неудобства.
Ну это и есть подмена домена - получить на него сертификат и подложить в локалку, обманув заодно DNS.
Криво, но работает.
При том, что по факту там ни домен, ни CA не нужны - но для работы PWA требуется.
В чем обман днс? Поднял локальный днс сервер и прописал на нем локальный адрес домена. Что не так?
Ну или даже не на локальном днс сервере прописать локальный адрес домена
Для LE нужен домен, который он может валидировать, т.е. снаружи - какой-то вебсервер, умеющий дать ответ.
При этом внутри локалки ДНС укажет на внутренний сервер, без выхода наружу.
В общем-то ничего сложного, просто по факту лишние телодвижения, когда хватило бы обычного самоподписанного сертификата, лет так на 10. Но браузер не любит их.
Если планшеты такие зарезанные, то подкинуть самоподписанный локальный сертификат тоже не проблема. Даже на iOS root-ca подкидывали и ничего, всё работает как надо.
Secure context в принципе даже в локальной сети правильно делать, просто потому что катать трафик plain-text'ом по wifi это прям совсем надо забить на безопасность (тут достаточно перехватить трафик и получить все пароли). А для PWA он прям реально нужен, потому что там service worker прям очень дофига какими привилегиями обладает и при его подмене можно прям устроить "дикую охоту" в сети.
del
Как вы обновляете service worker для PWA в которых есть формы? По идее нужно реализовывать какое-то действие подтверждения, чтобы данные которые ввел пользователь в форму, не сбросились при перезагрузке страницы.
Сервис-воркер никак не связан с формами на странице. Это отдельный js-файл, который регистрируется и висит в фоне. Заполнение формы при перезагрузке страницы может быть выполнено разными способами, но я не представляю ни одного, на который может повлиять обновление сервис-воркера.
Имеется в виду случай, когда приложение обновилось в момент заполнения формы. Соответственно бандл приложения так же может измениться, и если не перезагрузить страницу, то есть вероятность перехода по старым кускам кода (может тут не прав). Если страницу не перезагружать, то насколько понимаю, старые части бандла будут браться из кэша за который отвечает service worker. И вот тут самый главный вопрос - в какой момент времени будет загружен новый бандл? Как-то в фоне без обновления страницы или нет? И не сломает ли обновление бандла в фоне существующее состояние приложения (открытые диалоги, заполнения форм и прочее). Получилось довольно таки сумбурно, но думаю основной посыл понятен.
Может быть кто знает, как гарантированно заставить браузер показать диалог с предложением установить pwa приложение?
И как добиться того, чтобы приложение работало оффлайн даже через неделю без его запуска (то есть сразу после установки, приложение работает без доступа в интернет, но спустя некоторое время, по моим наблюдениям около недели, белый экран и всё)?
Если что, я использую фреймворк Quasar, где сборка pwa приложения идёт через его cli.
Поп ап или модалка не подходит?
let deferredPrompt;
window.addEventListener('beforeinstallprompt', (evt) => {
// Останавливаем показ диалогового окна установки
evt.preventDefault();
// Сохраняем событие в переменной, чтобы использовать его позже
deferredPrompt = evt;
});
Далее в коде сами можем вызвать deferredPrompt.prompt(); в любой момент. Например, по нажатию пользователем на кнопку.
Разрабатываем PWA. Полная инструкция по работе с Web App Manifest и Service Worker