2012-01-29 2 views
5

Предположим, я разработал сайт социальной сети, и я решил, что я хочу, чтобы ядро ​​приложения было полностью REST'ed. Пользователь регистрируется с паролем. Теперь, мой вопрос заключается в том, что для каждого запроса требуются пароли и пары входа (при условии, что вам необходимо указать вашу личность) в конце URL-адреса, например www.site.com/index.php?p=pass&l=login? Я бы немного нервничал по поводу просьбы об этом по каждому запросу. Я знаю, что у меня что-то не хватает ... это не может быть так, потому что кто-то может всплывать в пакеты и легко записывать пароль и логин. Я не думаю, что все запросы, сделанные в HTTPS, имели бы смысл (я читал, что это налогообложение ресурсов).У REST API требуется пароль и логин при каждом запросе?

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

+2

Исследовать * запрос на подпись *, OAuth и/или другие механизмы аутентификации на основе маркеров. У меня нет времени, чтобы написать это как полный ответ, но это должно дать вам кое-что для поиска. – deceze

+0

спасибо - обязательно прочитайте о них – netrox

ответ

12

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

Теперь о прохождении имен пользователей и паролей: обычно у вас есть «токен доступа к API» или тому подобное. На самом деле это не имя пользователя/пароль, но когда у кого-то это есть, им предоставляется возможность делать запросы API. Они могут иметь ограниченную или неограниченную юридическую силу. Вы даже можете сделать токен подписи - пользователь подписывает запрос с помощью некоторого ключа, и вы подтверждаете подпись.

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

+1

+1 для обеспечения безопасности перед исполнением. Эти сохраненные циклы ничего не стоят, если вы потратите неделю на аварийное восстановление! – jprofitt

1

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

6

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

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

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

OAuth Flickr diagram

Взято из: http://www.flickr.com/services/api/auth.oauth.html#access_token

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