@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. Если идентичны, то юзер успешно авторизован.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы