честно говоря, не знаю, как на ios реализована защита от кражи otp, то есть каким образом ios понимает, в какое приложение можно предлагать в клавиатуре подставлять код, а в какое нет
если мимо будут проходить ios-разработчики, подскажите пожалуйста)
это значит, что доступ на чтение смс есть только у приложения с нужной подписью. а вычислить по hash подпись приложения и подписать ей свое apk нельзя, поэтому злоумышленник не сможет сделать второе приложение, к которому будет подходить hash
бандит может скопировать hash из смс и прислать свое смс с этим hash, но все что он добьется — исходное приложение сможет автоматически считать этот код
коллеги подсказывают, что вероятно это скриншот для РБ, в РФ есть просто возможность включить/отключить все куки на сайте, так как законодательство не требует детальной настройки
например, пользователь подтвердил, что ему можно смотреть на товары 18+
мы можем положить в куки информацию об этом
все дальнейшие запросы на бекенд (например, получение картинок для карточки товара) будут содержать эту куку
и бекенд сможет по ней понять, можно пользователю отправлять картинку или нет
при этом сервису, отвечающему за картинки, не придется делать запрос в сервис, отвечающий за информацию о юзере - экономим миллисекунды и rps
но в основном конечно куки идеально подходят для токенов авторизации - прикрепляешь токены к домену, и они сразу начинают улетать со всеми запросами, не нужно их "прикладывать" к каждому запросу вручную
но хотелось бы уточнить - и остальные технологии, описанные выше, совсем не то, с чего стоит начинать
о них стоит задумываться как раз в тот момент, когда всё неплохо работает на простых "fragment (xml) + live data + viewmodel + менеджеринг многопоточности" и уже хочется ускорить процесс разработки/попробовать что-то новое
для написания кода под определенную версию пишутся просто проверки
if(android.os.Build.VERSION.SDK_INT >= n) { ... }
а Build Flavors - именно про разработку нескольких версий, отличающихся по функционалу и дизайну (отличающихся, не по причине разницы версий андроида, а из-за потребностей бизнеса)
когда в компании\стартапе разрабатываются два приложения для разных типов пользователей например, одно с доступом к функциям администратора и всем остальным функционалом, а второе - просто со всем остальным функционалом. в этом случае для безопасности можно всем пользователям рассылать урезанную версию, а администраторам полную (на сколько это в реальности прибавляет безопасности - хороший вопрос)
но более частый кейс - платная и бесплатная урезанная версия
Отличная работа. Описывал в своем блоге эту же схему с Handler, Looper, Message (https://t.me/dolgo_polo_dev/31), но в силу формата укладывался в 300 слов)
а тут с одной стороны сказано то же самое, но намного нагляднее. круто!
тоже имею очень небольшое отношение к ведению курсов в бауманке, так что привет коллеги)
но вопрос в другом. недавно тоже завел свой тг-канал, именно от лица разработчика
и столкнулся с огромной проблемой - абсолютно нет способов, позволяющих узнать потенциальной аудитории о существовании твоего канала
единственный способ "рекомендаций" - реклама в других тг-каналах. которая: а) дорогая (по вашим подсчетам 50р за подписчика - и это очень реалистичная цифра) б) по дефолту вызывает негатив у пользователей, ведь "реклама = зло"
конечно, это супер грубое нарушение и за такое надо бить по рукам. по-этому есть раздел «дисклеймер», в котором отметил, что код нарочно упрощен, и все не касающееся именно поставленной задачи отброшено
сколько раз спрашивать разрешение - один или на каждый раз - зависит только от разработчиков
некоторые решают после первого отказа запомнить этот выбор, некоторые будут пытаться каждый раз
да, hash всегда одинаковый, так как подпись приложения не меняется
а насчет разрешения, в каких флоу оно не нужно? разве есть сценарии, когда можно прочитать произвольное смс из приложения?
честно говоря, не знаю, как на ios реализована защита от кражи otp, то есть каким образом ios понимает, в какое приложение можно предлагать в клавиатуре подставлять код, а в какое нет
если мимо будут проходить ios-разработчики, подскажите пожалуйста)
hash зависит от подписи приложения
это значит, что доступ на чтение смс есть только у приложения с нужной подписью. а вычислить по hash подпись приложения и подписать ей свое apk нельзя, поэтому злоумышленник не сможет сделать второе приложение, к которому будет подходить hash
бандит может скопировать hash из смс и прислать свое смс с этим hash, но все что он добьется — исходное приложение сможет автоматически считать этот код
коллеги подсказывают, что вероятно это скриншот для РБ, в РФ есть просто возможность включить/отключить все куки на сайте, так как законодательство не требует детальной настройки
например, пользователь подтвердил, что ему можно смотреть на товары 18+
мы можем положить в куки информацию об этом
все дальнейшие запросы на бекенд (например, получение картинок для карточки товара) будут содержать эту куку
и бекенд сможет по ней понять, можно пользователю отправлять картинку или нет
при этом сервису, отвечающему за картинки, не придется делать запрос в сервис, отвечающий за информацию о юзере - экономим миллисекунды и rps
но в основном конечно куки идеально подходят для токенов авторизации - прикрепляешь токены к домену, и они сразу начинают улетать со всеми запросами, не нужно их "прикладывать" к каждому запросу вручную
огонь
для полного счастья не хватает только сверх умного поиска, который понимал бы тебя на человеческом языке
"покажи все классы, которые работают с данными из этой базы данных"
я до сих пор слабо понимаю принцип, по которому он некоторые вещи находит, а некоторые нет
поэтому иногда прибегаю к "тупо найди совпадения", когда знаю точную строку
но 90% процентов конечно покрывает поиск по double shift
adb emu network speed gsm
ограничивает скорость интернета
полезно для тестирования приложения на медленном интернете
если речь про https://github.com/Genymobile/scrcpy, то он под капотом использует adb, и вероятно просто перебрасывает туда этот аргумент)
>
scrcpyexecuteadbcommands to initialize the connection with the devicehttps://raw.githubusercontent.com/Genymobile/scrcpy/master/FAQ.md
а memsys также для тестов используете (смотреть нагрузку) или есть еще применения?
думаю, основную выгоду от этих абстракций можно получить на крупных проектах с множеством разработчиков
то есть их основная цель - не дать каждому разработчику писать своё решение на каждый процесс
например, flow - казалось бы, напиши свои коллбеки на корутинах, пропиши сценарии переполнения и готово...
но когда я вижу у кого-то стандартный StateFlow - я сразу уверен, как оно работает и используется в проекте
когда я вижу кастомные SingleValueAnySubscribersDeleteIfNoSubsCallback, мне нужно потратить время, чтобы поверить в логику его работы
в целом согласен
но хотелось бы уточнить - и остальные технологии, описанные выше, совсем не то, с чего стоит начинать
о них стоит задумываться как раз в тот момент, когда всё неплохо работает на простых "fragment (xml) + live data + viewmodel + менеджеринг многопоточности" и уже хочется ускорить процесс разработки/попробовать что-то новое
интересно, это предположение или инсайт из одной из реальных известных компаний?)
смотря что имеете ввиду
если "версия возможно с багами" и "версия проверенная" - то это ветки гитхаба
если разные настройки сборки - то это Build Types
если разный функционал (почему-то) - то это Build Flavors
нет нет, это совсем про другое
для написания кода под определенную версию пишутся просто проверки
а Build Flavors - именно про разработку нескольких версий, отличающихся по функционалу и дизайну (отличающихся, не по причине разницы версий андроида, а из-за потребностей бизнеса)
когда в компании\стартапе разрабатываются два приложения для разных типов пользователей
например, одно с доступом к функциям администратора и всем остальным функционалом, а второе - просто со всем остальным функционалом. в этом случае для безопасности можно всем пользователям рассылать урезанную версию, а администраторам полную
(на сколько это в реальности прибавляет безопасности - хороший вопрос)
но более частый кейс - платная и бесплатная урезанная версия
Отличная работа. Описывал в своем блоге эту же схему с Handler, Looper, Message (https://t.me/dolgo_polo_dev/31), но в силу формата укладывался в 300 слов)
а тут с одной стороны сказано то же самое, но намного нагляднее. круто!
тоже имею
оченьнебольшое отношение к ведению курсов в бауманке, так что привет коллеги)но вопрос в другом. недавно тоже завел свой тг-канал, именно от лица разработчика
и столкнулся с огромной проблемой - абсолютно нет способов, позволяющих узнать потенциальной аудитории о существовании твоего канала
единственный способ "рекомендаций" - реклама в других тг-каналах. которая:
а) дорогая (по вашим подсчетам 50р за подписчика - и это очень реалистичная цифра)
б) по дефолту вызывает негатив у пользователей, ведь "реклама = зло"
нашли ли вы другие способы рассказать о себе?