@icefog2016
Working

Мобильное приложение: как знать, что юзер тот самый?

Всем привет,
Заранее сорри за сумбур :)

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

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

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

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

Сегодня смотрю в сторону Оаут 1.0 и чето мне не по себе, мне кажется я вязну в этом, есть другие вещи которые нужно закончить, может я слишком заморачиваюсь?

Еще раз не имею опыта во всем этом, гугл мой опыт.
Но имею представление. Так в общих чертах.
Приложение на ионик 2.

Как правильно сделать эту чертову проверку?
Из-за цейтнота бросаюсь на вещи нахрапом, все с рук валится.
  • Вопрос задан
  • 498 просмотров
Решения вопроса 2
@SZolotov
Asp.net core, MAUI,WPF,Qt, Avalonia
Обычная практика после аутентификации на сервере передавать клиенту токен, который отправляется на сервер с каждым запросом клиента. По этому токену и проходит проверка. Для своих приложений oauth можно не использовать, это все таки больше для сторонних.
P.S. Смотрите в сторону апи вконтакта и фейсбука
Ответ написан
Я, конечно, криптограф диванный, но, возможно :
1. устанавливать соединение по HTTPS
2. передавать пароль в POST
3. сравнивать хеш пароля и сохранённый в БД хеш
Не?
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
iLeonidze
@iLeonidze
xbooster.ru
Сохраняйте в клиента хэш логина и пароля а-ля md5($login."_".$password), затем при каждом соединении по HTTPS с явной проверкой сертификата передавайте этот хэш на сервер. Перед исполнением любых операций проверяйте в БД пользователя по хэшу (прям в бд уже кладете сохраненное значение хэша) и все, вот и вся магия. Собственно, например, если рассматривать как работает веб-авторизация, то при вводе лог/пасса, сервер отдает клиенту куки, которые в свою очередь клиент постоянно шлет серверу. Вам оно не нада, ваша логика приложения значительно проще, так используйте это :)
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
SKEY(парольный хэш) - храним на клиенте и на сервере.
Он генерируется однократно при регистрации (например, присылается по электронной почте) и никогда не передаётся по сети в дальнейшем.

1. Сервер передаёт свой рандом клиенту (случайная строка): SERVER_RANDOM
2. Клиент генерирует свой рандом CLIENT_RANDOM и вычисляет CLIENT_HASH: HASH(SKEY+SERVER_RANDOM+CLIENT_RANDOM).
3. Сервер получает от клиента итоговый CLIENT_HASH и CLIENT_RANDOM.
4. Затем, сервер сверяет полученный от клиента CLIENT_HASH и HASH, посчитанный самостоятельно:
CLIENT_HASH===HASH(SKEY+SERVER_RANDOM+CLIENT_RANDOM)
,
5. Если идентичны, то юзер успешно авторизован.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
YCLIENTS Москва
от 200 000 до 350 000 ₽
Ведисофт Екатеринбург
от 25 000 ₽
ИТЦ Аусферр Магнитогорск
от 100 000 до 160 000 ₽
25 апр. 2024, в 11:49
25000 руб./за проект
25 апр. 2024, в 11:37
40000 руб./за проект