Интерфейс API Client с REST Использование Slim Framework

У меня есть простой REST API (с использованием Slim framework), где пользователь может вызвать такую страницу:

subdomain.domain.com/api/musician/id/3273

для извлечения и отображения некоторых простых данных JSON.

Я хочу добавить к нему некоторую аутентификацию, чтобы доступ к этим данным могли получить только пользователи с каким-то идентификатором клиента (как минимум). Я хотел бы, чтобы пользователь мог передавать свою секретную/идентификационную информацию своего клиента в URL-адресе, но я хочу снять это, не слишком сильно разбивая структуру REST.

Существует ли определенная структура или библиотека, которые будут особенно эффективны для достижения этого?

Ответ 1

У меня тоже был этот вопрос некоторое время, у меня также есть вопрос без ответа относительно этой самой темы (здесь так).

В основном ваши варианты - это OAuth или что-то обычное.

Теперь, для oauth, они работают над версией 2.0, и вы не должны запускать новый проект с использованием OAuth 1, но дело в том, что oauth2 еще далек от завершения, и небольшая поддержка сервера oauth2 для php прямо сейчас. Я не хочу говорить, что oauth2 2-legged/3-legged сложный, но это больше, чем нужно, а также после прочтения многих сообщений об этом, я решил, что на данный момент я должен пойти с чем-то еще, а не oauth (также один из создателей oauth покинул проект, потому что он был недоволен направлением этого проекта), потому что он находится в "неопределенном" состоянии (конечно, люди будут утверждать, что в значительной степени готовы к использованию, но мне все равно, я хочу, чтобы что-то уже было доказано, не хочу быть лабораторной крысой для огромных компаний, чтобы проверить oauth [да, oauth касается огромных интересов компаний, а не ваших]).

В любом случае, возвращаясь к моей проблеме, мне всегда нравилось, как Amazon работает с их api, это так просто реализовать, так почему бы не пойти в одном направлении? Я имею в виду, что Amazon является одним из крупнейших провайдеров api, если они его используют, у них есть настоящая причина для этого.
Сказано и сделано, менее чем за 2 часа у меня был протокол проверки подлинности/авторизации, и угадайте, что это было легко, просто и мне нравится писать (не разочаровываться из-за oauth). Хорошей статьей, которая помогла мне начать, было следующее: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/, который в основном показывает, что вы должны делать.

Итак, если бы я был вами, я бы начал оттуда:)

Ответ 2

Если ваши клиенты API не действуют "от имени" ваших пользователей, тогда OAuth, по моему мнению, чрезмерен.

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

Некоторые примеры Slim: здесь и здесь

Ответ 3

Возможно, это может быть полезно slim HttpBasicAuth

Вы можете использовать HTTP basic auth для запроса, чтобы проверить, является ли пользователь, выполняющий запрос, действительным пользователем.

Ответ 4

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

Таким образом, каждый пользователь аутентифицирует пользователя каждый раз, или временный cookie + сеанс, или, если у вас есть сторонние стороны, OAuth.

См. также Dave Ingram - презентация API-дизайна