В настоящее время я планирую реструктуризацию веб-приложения, чтобы отделить API от приложения. Прямо сейчас пользователи входят в приложение, вводя свой идентификатор оператора (имя пользователя) и пароль в стандартную форму HTML, и аутентификация выполняется путем проверки таблицы базы данных и создания сеанса PHP (обрабатывается с использованием Zend_Session
). Я не уверен, как продолжить делать это после отделения API.
Вот некоторый упрощенный код для иллюстрации того, как все работает в данный момент:
// GET https://foo.example.com/module/trips.php
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
require 'views/trips.php';
}
// POST https://foo.example.com/module/trips.php?action=take
// ...
// this request can come from AJAX, for example
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
$model->assignTrip($SESSION->operatorID, $_POST['trip_id']);
}
Очевидно, что это не очень RESTful, следовательно, усилия, чтобы разделить два. Это то, что я предложил (все еще в стадии разработки):
// GET https://api.foo.example.com/v1.0/trips
echo json_encode($model->getAllTrips());
// POST https://api.foo.example.com/v1.0/trips/:trip_id/operator
$model->assignTrip($_POST['operator_id'], $trip_id);
Я понимаю, что REST без гражданства. В этом упрощенном примере только оператор должен иметь возможность назначить себе поездку. Как мне применить это с помощью API?
Я прочитал много-много вопросов и статей об аутентификации с помощью API REST, и все они говорят об OAuth / OAuth2, который, кажется, отлично подходит для аутентификации клиентов API с помощью токенов, но ничего об аутентификации пользователей API-клиента (или, возможно, я неправильно понимаю что-то?) В моем случае мой клиент API все еще является веб-приложением.
Мой главный вопрос: Как API должен определять, кто пользователь? Или это вообще должно быть?
В качестве альтернативы я решил сделать это в веб-приложении:
// POST https://foo.example.com/module/trips.php?action=take
// ...
// this request can come from AJAX, for example
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
// Use cURL to send an HTTP POST request with the appropriate data to
// https://api.foo.example.com/v1.0/trips/6/operator
}
Это кажется ненужным, но вот как это выглядит в этом ответе. Я думал, что после моей реструктуризации я должен делать что-то вроде этого из JavaScript:
$.ajax({
type: 'POST',
url: 'https://api.foo.example.com/v1.0/trips/' + trip + '/operator',
data: {
operator_id: 6601
}
}).success(function() {
// It worked!
});
Я смотрел на GitHub API Authentication в качестве примера и использует базовое использование curl -u "username" <api-endpoint-url>
, Я не обеспокоен использованием Authorization
Заголовок HTTP, так как это приложение уже только HTTPS, но в этом случае мне не нужно хранить пароль локально (например, веб-хранилище или что-то еще)?
Я также прочитал этот блог и я не уверен, что это то, что я должен делать, и если да, то должен ли я включать имя пользователя и пароль в этот хэшированный блок данных?
Возможно, я неправильно понимаю, как API должны работать в целом, если так, то было бы здорово, если бы кто-то это прояснил!
Я согласен, что отправлять некоторые данные заголовка и хранить их локально странно, но, поверьте, это так.
Вы можете взглянуть на Аутентификация HMAC.
Многие API сегодня используют его или адаптируют для работы. Вы когда-нибудь отправите какой-нибудь идентификатор пользователя в заголовке, соединенный с вашим хешем. Сервер распознает пользователя по этим читателям.
Вам не нужно хранить пароль локально, только хеш (или токен), отправленный сервером, когда сделан запрос на аутентификацию.
Очистить все:
Других решений пока нет …