Я бы не сказал, там больше менеджерские навыки потребуются для 99% задач. Но вот если хочется попасть к тем мозговичкам, что будут новые ИИ пилить, тут да, математика нужна.:)
А. ServiseWorker'ом может быть только конкретный url с того же origin. Никаких виртуальных файлов, никаких файлов с другого, более надёжного, домена.
Б. Браузеры по спеке всегда лезут проверять его обновление.
Так что если есть опасность, что сервак захватят, то "нормальное" решение тут только одно: не использовать ServiceWorker(и соответственно PWA). Руками всё кэшировать в какой-нить indexedDB и костылить.
Вот это мы можем сломать?
Ты не сможешь сломать код регистрации(даже еслиб он на что-то влиял), потому что сам этот код(код странички) тоже контролируется воркером, который обновляется браузером независимо. Т.е. на момент старта PWA он пойдёт в первую очередь в воркер и возьмёт код странички оттуда из кэша. Соответственно если воркер уже скомпрометирован, то и страничку он вернёт поправленную сразу.
P.S. Ну разве что что-то стрёмное городить:
1. Грузить весь front-end сайта по "неподбираемой"(напр с uuid) url на "надёжный" сайт типа гугла (который точно не будет анализировать 404 запросы).
2. Просить юзаера установить PWA оттуда
3. После установки удалять всё оттуда и забывать url.
Если редирект гаратирован, то вечный промис - нормальное решение: он повисит сколько-то миллисекунд, пока страница не будет выгружена и не будет загружена новая.
В ином случае - только кидать и обрабатывать ошибку со специальным кодом.
Vitaliy Ivanov, схему не особо понял:), но могу сказать что в принципе возможны любые конфигурации в рамках задачи, как бы не крутили, просто одни проще, другие сложнее.
Евгений, "домашний сервер" - это сервер, который стоит дома. Белый ip тут вообще за рамками задачи - его провайдер выдаёт, который за пределами того, что там намутит в любом случае.
Могу только сказать что в рамках домашней сети никакого VPN и туннелирования не надо, нужна той или иной сложности маршрутизация нормального сетевого трафика, в зависимости от желаемой конфигурации.
В идеале вы делаете из сервера полноценный роутер(помимо всего прочего), а роутер используете как простой свич(точку достпа):
клиенты - роутер(как свич) - сервер(как роутер) - интернет.
Это самый простой и логичный вариант, но можно и навертеть.
Евгений, предполагаю, что скорее всего автор хочет так:
клиенты - роутер - сервер - (обратно)роутер - интернет
Почему не логичная система где:
клиенты - роутер(в режиме свича) - сервер(как навороченный роутер) - интернет
Хз, но мб в сервере нет двух сетевух, или нет оптовой, или роутер специальный провадерский... Ну или, конечно, возможно просто непронимание базы.:)
Т.е. интернет на объекте есть(хотяб внутренний, чтоб софтина работала)?
Коли да - просто ставь любой софт удалённого доступа(anydesk, vnc какой-нить) на комп с программой и клиент на планшет, всего делов.
Это точно будет работать, и возможно даже лучше чем голая софтина, заработанная без учёта тача.
С некоторым шансом будет работать тупо прям в винде коли джава, как заметили выше.
Установка линь на планшет, а потом поверх сотины - имеет сугубо теоретический шанс на работу.:)
Про вычисление рандома по распределению - херня, никто этого не будет делать, больше ресурсов уйдёт чем пользы. Только если прям массовый характер приобретёт благодаря какому-то популярному софту, тогда конкретно этот софт вычислять и будут.
По вычислению о заголовкам - да, всё зависит от того насколько хорошо софт имитирует браузер. Про конкретный ничего сказать не могу.
В идеале это должно быть расширение для браузера, тогда удачи им найти различия которых нет.
Проще взять за основу одну из систем, где больше всего уже предусмотрено и тупо дополнить и\или смапить в оную все остальные ошибки. Так будет меньше телодвижений, главное чтоб авторы системы не решили когда-нить её целиком перелопатить.:)
То что ты запрашиваешь страницу раз в 2 секунды они видят, точнее могут увидеть если захотят. Что-за веб-монитор - хз, если он нормально сделан то разницы меж тем что ты нервный шизик постоянно тыкающий f5 и программой увидеть нельзя. Только по косвенным: даже шизик не сможет это делать круглосуточно и с интервалом ровно 2с. Следовательно интервал надо романтизировать и на ночь софт отключать. :)
Сам по себе typescript вообще ничего не знает о Vue или о стилях, он только ts код проверяет.
Чтоб он "на лету" подхватывал виртуальные автосгенерирированные типы для стилей используются разные language service плагины для движка ts или вообще отдельные плагины для твоей IDE.
Это по сути очень замороченный и низкоуровневый костыль.
Тебе надо настроить, чтоб под капотом такого плагина сначала компиллился твой scss в css, а уж потом генрировал тайпинг, чего сейчас не происходит, полагаю, из-за вопросов производительности.
Возможно ли это без сложных телодвижений? Хз, надо изучать материалы по ссылке приведённой выше.:)
P.S. "Классическое" решение - просто отдельно запускать хрень(их несколько разных) которая будет следить за изменением файлов и генерить .d.ts, которые будет подхватываться на лету. Но так у тебя будет куча мусорных .d.ts'ок валяться, которые ещё и врать могут, если хрень забыл запустить или она отвалилась.:)
