2013-09-25 2 views
1

Новые услуги RESTful, но много читайте на эту тему. Реализация в VS2010 C#Restful Login - надлежащая реализация

Были заданы одинаковые (почти идентичные) вопросы и ответы на них приведены в stackoverflow, но, честно говоря, я ничего не узнал из ответов.

Я хочу реализовать вызов AuthenticatUser, где отправляется имя пользователя и пароль, и возвращается ключ аутентификации.

Учитывая, что это необходимо сделать с помощью GET, POST, PUT или DELETE, кажется, что GET будет наиболее подходящим.

Так что, возможно GET MYDOMAIN/MyService/аутентификации/{имя пользователя}/{пароль}

мне не нравится это, потому что имя пользователя и пароль передаются в URI, но, как я понимаю, это не хорошо идея отправить тело в GET. Таким образом, POST или PUT будут работать, но это, похоже, отличается от философии RESTFul.

Вопрос 1: Можно ли отправлять конфиденциальные данные, такие как пароль, в URL? Сайт будет использовать SSL.

Вопрос 2: В GET, когда передано несколько параметров, похоже, что концепция URI будет немного сумасшедшей, как сложные запросы должны обрабатываться RESTfully?

Вопрос 3: Какой предпочтительный (обычный, наиболее распространенный) метод аутентификации в RESTful API?

+0

Я думаю, вам нужно прочитать, что такое «RESTful», который честно ответит на большинство ваших вопросов. Кроме того, URL-адреса читаются в браузере, поэтому неразумно помещать любую конфиденциальную информацию в URL-адрес. –

+1

Как правило, ваша схема аутентификации будет включать * создание * объекта сеанса (обычно в базе данных на сервере), поэтому PUT или POST с учетными данными пользователя полностью соответствуют. – JDB

+0

Интересно взять POST, создав объект сеанса на стороне сервера, но, похоже, это унижает дух архитектуры с технической точки зрения. Что касается чтения, у меня есть - он все еще гелевидный, я даже читал доктор Филдинг. Я использовал S3 Amazon, который, как я понимаю, REST, но при покупке нам назначается ключ аутентификации, и он используется для запроса сервисов. – kpg

ответ

1

Неправильно пропускать пароль в url. Я провел некоторое исследование по этому вопросу. Во-первых, вы должны использовать Basic Authentication over SSL, если это возможно. В заголовке «Аутентификация» передайте идентификатор пользователя и пароль. Теперь, что касается отдыха, сеанс не поддерживается на сервере. Поэтому вам необходимо передать идентификатор пользователя и пароль для каждого вызова. Хранить пароль в локальном хранилище опасно. Следовательно, используйте POST-вызов для аутентификации в первый раз и передайте идентификатор пользователя и пароль. Затем при возврате успешной аутентификации сервер возвращает токен и значение токена. tokenkey и tokenvalue похожи на долю частного ключа Amazon изначально. После следующего запроса отправляйте токен и подпишите свои данные, используя значение tokenvalue. Каждый раз передавайте токен и подпись. В serverend сервер проверяет подпись, так как она имеет копию значения tokenvalue. tokenkey и tokenvalue могут храниться локально, если это возможно, зашифрованы. Вы не можете использовать tokenkey и tokenvalue навсегда. Следовательно, по каждому запросу сервер отправляет сообщение nonce в ответ. Это nonce хранится в базе данных на сервере и изменяется для каждого запроса. Когда вы отправляете запрос на сервер, укажите это nonce. Nonce формируется с использованием метки времени. Если запрос отправляется, скажем, через 15 минут, деление расшифровывается, а временная метка - более 15 минут, и поэтому вы перенаправляете его на страницу входа. Формирование Nonce приведено в http://www.ietf.org/rfc/rfc2617.txt. После того, как nonce успешно подтвержден, это nonce отбрасывается и теперь отправляется новое nonce (формируется снова с последней меткой времени). Это также поможет предотвратить повторную атаку.

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