Lumen — младший брат Laravel: быстрая и легкая микро-среда для написания RESTful API. Немного кода, вы можете использовать Lumen для создания безопасного и чрезвычайно быстрого RESTful API.
В этом видеоуроке из моего курса « Создание REST API с Lumen» вы узнаете, как использовать встроенное промежуточное программное обеспечение аутентификации Lumen для защиты REST API с помощью Lumen.
Видео ссылается на код из примера API музыкального магазина, который мы создали на предыдущих уроках курса. Вы можете просмотреть полный исходный код курса на GitHub .
Как защитить REST API с помощью Lumen
Аутентификация в Lumen
Безопасность — это очень важная часть не только веб-API, но и приложения. И, к сожалению, реализация аутентификации может быть сложной задачей. Но, к счастью, аутентификация встроена в Lumen, так что все, что нам нужно сделать, это включить аутентификацию и затем написать несколько строк кода для аутентификации пользователя, а затем еще несколько строк кода для защиты того, что мы хотим защитить.
В нашем примере мы хотим защитить три метода на нашем контроллере гитары. Это методы создания, обновления и удаления. Это вещи, к которым должен иметь доступ только авторизованный пользователь.
Итак, давайте начнем с того, что перейдем в папку начальной загрузки и откроем app.php.
Есть два утверждения, которые нам нужно раскомментировать. Первый — это вызов routeMiddleware , который устанавливает промежуточное ПО аутентификации. Мы также хотим зарегистрировать поставщика услуг авторизации. Итак, второй оператор — это $app->register(App\Providers\AuthServiceProvider::class); , Просто раскомментировав эти два утверждения, мы теперь можем использовать аутентификацию в нашем приложении.
Теперь мы хотим отметить наше промежуточное ПО аутентификации. Итак, давайте перейдем к App\Http\Middleware\Authenticate.php , и внутри этого класса есть метод с именем handle , и этот метод будет выполняться перед нашими защищенными методами.
Поэтому всякий раз, когда мы делаем запрос на наши методы создания, обновления или удаления, будет использоваться промежуточное программное обеспечение для аутентификации, и этот метод handle будет вызываться.
Если пользователь не аутентифицирован, он вернет 401. В противном случае он передаст запрос следующей вещи, которая обработает этот запрос.
Так что это одна вещь, на которую мы должны были смотреть. Другой находится внутри папки «Поставщики», и это AuthServiceProvider.php.
Теперь в нижней части этого файла находится метод с именем boot , а внутри boot — вызов этого метода viaRequest . И это метод, который отвечает за подлинную аутентификацию пользователя. Так что это будет зависеть от нашей реализации. И на этом уроке наша реализация будет очень простой.
Мы собираемся проверить заголовок Api-Token. И если это определенное значение, то мы будем говорить, что пользователь аутентифицирован. Чтобы сказать, что пользователь аутентифицирован, мы должны вернуть экземпляр пользователя. Если мы возвращаем ноль, то это означает, что пользователь не аутентифицирован.
Итак, давайте продолжим и напишем этот код. Я собираюсь закомментировать этот существующий код. И первое, что мы собираемся сделать, это получить заголовок Api-Token. Итак, мы собираемся использовать наш запрос, мы будем вызывать метод заголовка и нам нужен Api-Token.
|
1
|
$header = $request->header(‘Api-Token’);
|
Теперь позвольте мне прежде всего сказать, что это небезопасно. Мы определенно хотели бы хранить наших пользователей в базе данных. У каждого из них должны быть свои уникальные токены, и на самом деле мы должны работать с закрытыми и открытыми ключами. Но я собираюсь оставить все детали реализации до вас. Мы хотим видеть, как промежуточное программное обеспечение для аутентификации подключается к нашему приложению, чтобы мы могли работать, и тогда вы можете реализовать все, что захотите.
Итак, мы собираемся получить заголовок под названием Api-Token. И давайте сначала проверим, есть ли у нас что-то там.
Теперь, единственное, что нам нужно сделать, это сказать, где мы хотим использовать наше промежуточное программное обеспечение для аутентификации. Мы можем сделать это в разных местах.
Первый — всякий раз, когда мы определяем наши маршруты. Например, мы хотим защитить наш почтовый запрос. Поэтому вместо того, чтобы писать наш маршрут, как мы, мы могли бы сделать это. По сути, это то же самое, но второй аргумент, который мы передали методу post, будет иметь два ключа и значения.
Поэтому, не углубляясь в дальнейшие действия, мы могли бы сесть на Fiddler и сделать запрос по почте, чтобы узнать, будет ли это защищено.
Одна из замечательных особенностей Fiddler заключается в том, что он отслеживает все запросы, которые мы сделали. Так что нам просто нужно найти, где мы сделали запрос POST. И если мы попытаемся выполнить это, мы получим 401. Но если мы включим этот заголовок Api-Token, и если мы установим его как «птицы летят на юг», то всякий раз, когда мы делаем этот запрос, мы получаем 200, и мы уже знаем, что эти данные сейчас находятся в базе данных.
Так что это первый вариант. Но второй вариант — указать наше промежуточное ПО внутри конструктора нашего контроллера. Итак, давайте закомментируем код, который мы только что написали, и вместо этого используем наш старый маршрут.
Давайте перейдем к нашему гитарному контроллеру и добавим следующий код:
Поэтому, если мы вернемся к Fiddler и выполним тот же запрос — давайте просто изменим значение на strat, а make на Fender — тогда мы увидим, что он все еще работает. Поэтому, когда мы выполняем этот запрос, мы получаем 200. Если мы достанем Api-Token, то получим 401.
Теперь давайте также выполним некоторые другие запросы. Итак, давайте сделаем запрос GET, чтобы мы могли получить эти гитары и получить их идентификаторы. Давайте избавимся от Api-Token просто так, чтобы мы могли видеть, что это работает без какого-либо типа аутентификации. И мы получаем ID 1 и ID 2.
Итак, если мы вернемся к композитору, давайте сделаем запрос PUT для гитары с идентификатором 2.
Для данных, которые мы собираемся отправить, маркой будет Fender, но давайте изменим модель со страты на телекастера. Теперь без Api-Token это не должно работать. Поэтому всякий раз, когда мы выполняем, мы получаем 401. Но давайте добавим Api-Token, а затем значение, птицы летят на юг, и этот запрос вернет 200.
Так что просто для полноты давайте сделаем запрос DELETE. Давайте удалим гитару с идентификатором 1. Мы должны получить 200, и давайте повторно выполним запрос на получение всех наших гитар. И у нас должен быть только один, и у него должен быть ID 2. Марка Fender, а модель — телекастер.
Поэтому добавить аутентификацию в приложение Lumen очень и очень просто. Помимо добавления промежуточного программного обеспечения, основная часть кода, который вам нужно написать, находится внутри класса AuthServiceProvider . Вы должны написать код, отвечающий за аутентификацию пользователя, но как только это будет сделано, вы получите безопасный API.
Смотреть полный курс
В полном курсе « Создание REST API с помощью Lumen» я покажу вам, как начать создавать REST API с помощью инфраструктуры Lumen. Вы начнете с настройки среды разработки Lumen и приступите к созданию полного API для музыкального магазина, включая маршрутизацию, подключение к базе данных MySQL и безопасность.