2015-09-23 2 views
2

Я установил REST API на свой сайт, чтобы возвращать информацию из моей базы данных.Проверка учетных данных пользователя с помощью REST API?

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

Поскольку мой REST API не является открытым для общественности, было бы безопасно передавать данные, как это:

/users/verify/email/{email_address} 
/users/verify/password/{password} 

Или есть лучше (безопаснее) способ сделать это? Другими словами, как я могу аутентифицировать и проверять пользователей при регистрации/регистрации?

+0

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

ответ

1

Вы можете использовать POST метод.

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

Просто убедитесь, что вы не передаете пароль в ясном виде. Выполните на нем какое-то шифрование.

+0

И отправить клиента со статическим предварительно сконфигурированным криптографическим ключом? Он может быть извлечен из клиента. Вы можете отправить пароль в режиме очистки, но сделать канал связи безопасным. Используйте HTTPS. – Fred

1

Если ваш веб-сервис - это Asp.Net WebAPI, который вернет токен доступа для действительного пользователя, вы можете использовать запрос Http POST с именем пользователя и паролем в качестве содержимого тела.

Для образца кода, пожалуйста, посмотрите на мой ответ на следующий вопрос

Implementing Oauth2 with login credentials from native login page

Для лучшей безопасности, используйте Https вместо HTTP.

Надеюсь, это поможет!

1

В REST вы говорите о ресурсах. Ресурс будет иметь определенное состояние, выраженное через их свойства.

С вашим примером я бы спросил себя: «зачем проверять электронную почту», «зачем проверять пароль». Потому что вы хотите проверить, может ли пользователь быть зарегистрирован. Таким образом, ваш ресурс не будет являться адресом электронной почты или паролем, кроме пользователя.

Проверка - это действие. Что-то плохое с REST architecture.

Что вы хотите проверить? Вы хотите зарегистрировать нового пользователя, но также проверить, разрешено ли ему регистрироваться. Поэтому вы попытаетесь с некоторыми условиями добавить пользователя в свою коллекцию пользователей. В REST с HTTP это можно сделать с помощью POST, который действует как add (User). Логика запроса может затем реализовать правила проверки для пользователя.

Для публикации данных просто используйте тело контента и используйте заголовки для получения дополнительной информации. Так что я бы изменить свой API для:

HTTP method: POST 
Path: /users 
Content-Type: application/json 
Body: 
{"email_address":"[email protected]", "password":"qlmkdjfmqlsk"} 

что упрощает ваш API для одной точки входа для добавления пользователя. Разрешение или отказ от регистрации пользователя может быть передано посредством использования кодов состояния и сообщений HTTP.

Конечно, отправка паролей в текстовом виде не является хорошей практикой, но вы можете настроить безопасное соединение с SSL или TLS для связи.

Отправка конфиденциальных данных по URL-адресу не является хорошей практикой. Серверы могут регистрировать URL-адрес, который будет показывать всем, у кого есть доступ к журналу пароля пользователя.

Логин немного отличается, но не настолько.

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

HTTP method: POST 
Path: /authentication 
Content-Type: application/json 
Body: 
{"email_address":"[email protected]", "password":"qlmkdjfmqlsk"} 

Response

Status-Code: 200 
Content: 
unique-id-to-my-user 

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

Чтобы справиться с этим, вы можете использовать реализацию OAuth2.

Смежные вопросы