Laravel по-русски

Sanek

Сообщений: 18

Создание API, торчащего наружу.

Задача - нужно дать возможность извне подгружать некие справочные данные в БД.
Как правильно это сделать с точки зрения безопасности?
Пока такие мысли
1. Создать env константу например вида API_KEY = "12342fasdrf12342134sdfasdfq2341234asdfasdf1234"
2. Создаем Route::post('api/myMethod', 'MyApiController@myMethod')
3. Здесь добавляем этот url 'api/myMethod'
class VerifyCsrfToken extends BaseVerifier
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        //url запросов, для которых не нужно проверять CSRF токен
    ];
}

4. В самом 'api/myMethod' смотрим, если передаваемый API_KEY не совпадает, то отбреваем. Если совпадает, делаем что нужно.

Как этот вариант с т.зрения безопасности? Это штатное создание "внешнего" API?

nailfor +21

Сообщений: 40

Статей: 2

Re: Создание API, торчащего наружу.

Решение - хрень полная.. Первый кто получит API_KEY или подсмотрит его вирешарком сольет его всем желающим
Ко всему не отслеживается кто из пользователей создает запрос, а значит нет разделения на полномочия пользователей.

1. Для API лучше задать свой собственный роут исправив провайдер RouteServiceProvider
    public function map()
    {
        $this->mapApiRoutes();
        ...
    }
В mapApiRoutes отключаем ->middleware('web') которая и делает csrf, для API он не нужен
2. Создайте отдельный роут и контроллер к нему, создающий авторизацию и выдающий одноразовый ключ(ну или сессию на 20-30 минут)
3. Все последующие запросы осуществляйте с передачей этого ключа, например мы делаем через X-Session-Token: в хедере запросов, дабы отделить параметры запроса от технических коннектов к системе.
4. Для хранения временных токенов идеально подходит Cache - у него есть параметр длительности хранения.

Да прибудет с Вами святой Laravel и пророк его Eloquent

Sanek

Сообщений: 18

Re: Создание API, торчащего наружу.

(2) то что отдельный роут и контроллер это понятно.
А выдавать токен - по логину и паролю, передаваемым в заголовках?

Ну типа get метод, например getToken(), который проверяет логин пароль и возвращает сгенерированный токен.
Получаем токен, и передаем его в последующих запросах к API.
Я правильно понимаю?

Тогда чем "подсмотреть логин пароль" отличается от "подсмотреть API_KEY", не совсем понимаю.
Для каких целей вообще токен, если можно в заголовках передавать логин пароль и проверять его?

Да, пользователь предполагается один - "служебный" - для того чтобы внешняя система могла обмениваться с API

nailfor +21

Сообщений: 40

Статей: 2

Re: Создание API, торчащего наружу.

Да, правильно.

Отличается тем, что
1. Передача логин-пароля труЪ джыдаи делают через https и обязательно POST
2. При утечке налево логин-пароля учетка блочится(и вообще пароли полезно менять раз в 2 месяца или чаще) а при токене под удар подпадают все пользователи API
3. т.к. по факту токен - это один пользователь совершенно не представляется возможным разделить действие API

пользователь предполагается один

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

Для каких целей вообще токен, если можно в заголовках передавать логин пароль и проверять его?

можно и с каждым. Но больше телодвижений: создать хэш, сделать запрос к БД, сверить...
С токеном в кэшах - просто проверить есть такой ключ в кэше или нет.