Веб – это скам

Мобильный разработчик решил сделать веб-приложение, что могло пойти не так?

Контекст: мне нужно было сделать простое веб-приложение, в котором нужно дёрнуть пару запросов из апишки, предварительно получив токен аутентификации. Очень простая задача для мобильного разработчика.

Итак я расчехлил Compose Multiplatform для JS, начал работу и сразу же огреб 💀

Нужно редиректить на страницу аутентификации, а как это вообще сделать? Документация по KMP в JS оставляет желать лучшего, но благо ChatGPT тут помог и говорит, что мы можем просто использовать js подобный код в main функции, поэтому делаем так:
window.location.href = "your_url"

Ок, с этим разобрались, переходим на страницу входа и говорим, что хотим после успешного входа вернуться обратно в наше приложение, но ничего не работает, так как есть whitelist доменов, на которые можно возвращаться.. Поэтому идём в etc/hosts и прописываем другой домен заместо localhost.

Редирект заработал и после успешного логина в браузере проставляется кука, и я хочу ее прочитать в приложении, чтобы авторизовать запросы в апишку, но не тут то было, эту куку нельзя читать в js 🤯

Я думаю ок, токен можно и другими способами достать, пробуем дёрнуть запрос к апишке сервиса и получаем пинок от CORS. Браузер запрещает вам дергать произвольные апишки, если сервер, на который вы стучитесь не настроил корректные политики.

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

Поэтому в очередной раз убедился, что никакая кроссплатформа не избавляет вас от знания особенностей среды выполнения!

А про приключения мобильного разработчика в бекенде читайте в следующей серии 🤨

#KMP #JS #WEB
@kotlin_adept

Как подружить Web History и Compose resources

Недавно столкнулся с проблемой: после добавления поддержки Web History в проект с Compose для Web у меня перестали работать ресурсы, причём это происходило только на вложенных экранах.

Изначально я предположил, что проблема связана с настройками веб-сервера, но нет. В Compose для Web ресурсы загружаются по относительному пути. Это означает, что к текущему URL в браузере добавляется путь до ресурсов. Соответственно, если вы находитесь не на главной странице, то по такому пути ресурсы окажутся недоступными 🫥

Посмотрел, что пишут в документации, но никаких рекомендаций там не дается на этот счет, что довольно странно. Поправить же проблему удалось следующим образом:

configureWebResources {
    resourcePathMapping { path -> "${location.origin}/$path" }
}

Добавляем этот код в функцию main в сорсете jsMain, и пути до ресурсов снова становятся корректными.

#Compose #JS #WEB

Как слить кодовую базу из-за Compose Multiplatform

Я уже как-то писал, что никакая кроссплатформа не освобождает от необходимости знать среду выполнения, и это в очередной раз стрельнуло.

Если в Android мы переживаем за то, чтобы никто не зареверсил наш код, подключаем R8 и так далее, то как обеспечить такой же уровень защиты в вебе?

Казалось бы, там всё ок из коробки: в релизном билде что-то понять из итогового JS-файла не получится, особенно с Wasm.

Но есть один маленький нюанс: по умолчанию в настройках Webpack исходный код тоже публикуется, и его любой может успешно посмотреть в Developer Tools. А в документации по Compose Multiplatform нет ни одного упоминания о том, как это предотвратить 🤡

Так что обязательно отключайте публикацию сорсов в настройках Webpack на релизе. Как это сделать — смотрите в комментариях 👇

#Security #Compose #WEB