v
Не гарантирует сохранения, ЕМНИП
Size: a a a
2020 June 22
DB
Ну хранить лучше не логин пароль, а токен доступа, но в целом shared_preferences достаточно логичное для этого место. Ещё лучше если есть данные юзера помимо токена - хранить это все нормально в локальной бд с шифрованием.
Там ещё одна засада возникает — если у вас проект лежит в open source (как у нас), причём и серверная, и клиентская часть, то как добиться того, чтобы на запрос сервера клиент выдавал правильный ответ, но при этом сам алгоритм вычисления этого ответа невозможно было понять из кода?
Мы пока так придумали: bash-скрипт, который разработчик должен запустить перед очередным деплоем, который рандомно меняет код вычисления ответа на клиенте и сервере:
https://github.com/dbystruev/Get-Outfit/blob/master/api/randomize.sh
Мы пока так придумали: bash-скрипт, который разработчик должен запустить перед очередным деплоем, который рандомно меняет код вычисления ответа на клиенте и сервере:
https://github.com/dbystruev/Get-Outfit/blob/master/api/randomize.sh
v
А сикрет юзнуть?
EE
Там ещё одна засада возникает — если у вас проект лежит в open source (как у нас), причём и серверная, и клиентская часть, то как добиться того, чтобы на запрос сервера клиент выдавал правильный ответ, но при этом сам алгоритм вычисления этого ответа невозможно было понять из кода?
Мы пока так придумали: bash-скрипт, который разработчик должен запустить перед очередным деплоем, который рандомно меняет код вычисления ответа на клиенте и сервере:
https://github.com/dbystruev/Get-Outfit/blob/master/api/randomize.sh
Мы пока так придумали: bash-скрипт, который разработчик должен запустить перед очередным деплоем, который рандомно меняет код вычисления ответа на клиенте и сервере:
https://github.com/dbystruev/Get-Outfit/blob/master/api/randomize.sh
вынести в либуи не комитить ее
DB
вынести в либуи не комитить ее
Да, но тогда проект не соберётся у того, кто захочет повторить.
v
Почему?)
EE
но вообще оычно держат ве репки, приватную и пбуличную, при этом черепикают комиты из привата в паблик, что бы лишнего не утекло
EE
Да, но тогда проект не соберётся у того, кто захочет повторить.
приложи верисю либы которая работает не так как у вас
v
Вроде бы все достаточно прозрачно
На сервере сикрет, как клиент так и сервер может удостовериться что данные не подменены
На сервере сикрет, как клиент так и сервер может удостовериться что данные не подменены
DB
Вроде бы все достаточно прозрачно
На сервере сикрет, как клиент так и сервер может удостовериться что данные не подменены
На сервере сикрет, как клиент так и сервер может удостовериться что данные не подменены
В принципе, тоже решение, хотя приведёт к тому, что у 80%, кто клонирует проект, будет один и тот же алгоритм — люди не заботятся о безопасности.
А с рандомной генерацией кода по скрипту у всех точно алгоритм будет разный.
А с рандомной генерацией кода по скрипту у всех точно алгоритм будет разный.
v
та пофиг на алго)
сикретом пусть берут какой-то юид в переменные окружени и готово)
сикретом пусть берут какой-то юид в переменные окружени и готово)
DB
та пофиг на алго)
сикретом пусть берут какой-то юид в переменные окружени и готово)
сикретом пусть берут какой-то юид в переменные окружени и готово)
А, ну по сути, тоже менять код сервера и клиента, только менять одно значение — сикрет. И если стоит дефолтный, не изменённый, выдавать ошибку. Вариант.
v
А вам точно-точно нужно чтобы клиент знал сикрет?
v
Разве клиенту не достаточно проверить целостность данных?
VA
А, ну по сути, тоже менять код сервера и клиента, только менять одно значение — сикрет. И если стоит дефолтный, не изменённый, выдавать ошибку. Вариант.
Используйте OAuth2. Генерируйте при старте приложения токен.
DB
А вам точно-точно нужно чтобы клиент знал сикрет?
Клиент присылает токен (который ему сервер в прошлый раз выдал).
Сервер на основе токена генерит challenge.
Клиент на основе челенджа делает ещё один response token.
Сервер сверяет, что клиент сгенерил токен правильно, и пускает.
Сервер на основе токена генерит challenge.
Клиент на основе челенджа делает ещё один response token.
Сервер сверяет, что клиент сгенерил токен правильно, и пускает.
v
Что такое challange?
v
Сто слоев кода?)))
DB
Что такое challange?
Challenge — уникальный, сгенерированный на основе токена запрос, на который нужно дать правильный ответ
DB
Сто слоев кода?)))
Меньше двух запросов туда-обратно и двух ответов не получается, если планировать, что вся коммуникация может быть перехвачена и все токены видны стороннему наблюдателю