Подход отдыха: для реализации последующих вызовов API после входа в систему

Я пытаюсь реализовать подход Rest для разработки моего API.

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

  1. Клиент (веб-браузер) Остаточный вызов от клиента ->/post/login username/password

  2. Служба сервера/логина проверяет с БД правильность имени пользователя и пароля Отвечает ok:200 + отправляет данные обратно-> X

  3. Клиент получает подтверждение того, что пользователь аутентифицирован + данные -> X Теперь использует данные X для последующих вызовов на сервер, чтобы получить информацию о пользователе через другие сервисные вызовы.

/get/FirstName_of_User/X или

/get/LastName_of_User/X

теперь я сомневаюсь в следующем (как лучше всего сделать следующее)

  1. Поскольку для последующих запросов нам нужно сообщить сервису, чьи данные мы запрашиваем, каким должен быть X? (Имя пользователя или временный токен создан (не имеет смысла, так как Rest - это отсутствие гражданства) или что-то еще?)

  2. После того, как этот X будет возвращен, где он должен храниться на стороне клиента, чтобы на него можно было подать в суд для каждого последующего запроса? (Файл cookie или какой-либо другой способ существует)?

  3. если так я делаю последующие вызовы
    /get/FirstName_of_User/X

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

Сомнение 3 - я нашел эту ссылку в stackoverflow - Используется ли сеанс для аутентификации REST?

который предлагает использовать HMAC и нашел эту ссылку - http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/, в котором рассказывается о том, как HMAC можно использовать для Rest (в основном речь идет о наличии закрытого ключа как на клиенте, и сервер и использовать его для хеширования запроса).

Я сомневаюсь в этом подходе: скажем, я использую пароль в качестве закрытого ключа, о котором знают и клиент, и сервер. Тогда на стороне клиента мы должны просто сохранить пароль в файлах cookie для хэширования каждого последующего запроса?

Спасибо Любая помощь в любых сомнениях приветствуется

PS: я пытаюсь реализовать систему, используя PHP + Mysql


php rest hmac restful-authentication
person Juzer Arsiwala    schedule 30.04.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward 

/user/id?access_token=42342342342423

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

person Carlos Barbosa    schedule 30.04.2012
comment
согласно вашему примеру - для любого последующего запроса клиенту необходимо отправить -> id -> accesstoken. мои сомнения - 1> где клиент хранит идентификатор? как печенье? 2> какие шаги вы выполняете для создания токена доступа ?? и какие шаги выполняет сервер по получению токена доступа?? - person Juzer Arsiwala; 30.04.2012

arrow_upward
0
arrow_downward

Каким-то образом ваше требование и то, что мы реализуем в нашем проекте, выглядят одинаково, за исключением другой платформы, у нас .net.

Выполните тот же процесс для ресурса входа в систему с именем пользователя и паролем. Как только вы определитесь с механизмом, которым вы хотите подписать этот токен, его не обязательно всегда добавлять в URL-адрес.

  1. Вместо отправки токена в URL-адресе попробуйте его с заголовком авторизации протокола http. Используйте Authorization = "Authorization" ":" credentials ссылку

Таким образом, вы можете сохранить свой URL-адрес таким же, но на основе аутентификации вы можете обслуживать ресурсы.

  1. Вы можете сохранить этот токен в файле cookie для последующих запросов.

  2. Удаление токена из URL-адреса решает ваше третье сомнение.

Надеюсь, это поможет вам в некоторой степени.

person JPReddy    schedule 01.05.2012