Middleware
Введение
Посредники (англ. middleware) предоставляют удобный механизм для фильтрации HTTP-запросов вашего приложения. Например, в Laravel есть посредник для проверки аутентификации пользователя. Если пользователь не аутентифицирован, посредник перенаправит его на экран входа в систему. Если же пользователь аутентифицирован, посредник позволит запросу пройти далее в приложение.
Конечно, посредники нужны не только для авторизации. CORS-посредник может пригодиться для добавления особых заголовков ко всем ответам в вашем приложении. А посредник логов может зарегистрировать все входящие запросы.
Создание посредника
Чтобы создать посредника, используйте команду Artisan sh make:middleware :
Выполнение посредника «до» или «после» запроса
Момент, в который сработает посредник — до или после запроса, зависит от него самого. Например, этот посредник выполнит некоторую задачу прежде, чем запрос будет обработан приложением:
А этот посредник выполнит задачу после того, как запрос будет обработан приложением:
Регистрация посредника
Глобальный посредник
Назначение посредника для маршрутов
Когда посредник определён в HTTP-ядре, вы можете использовать метод middleware для назначения посредника на маршрут:
Для назначения нескольких посредников для маршрута:
Когда посредник определён в HTTP-ядре, вы можете использовать ключ middleware в массиве параметров маршрута:
Используйте массив для назначения нескольких посредников для маршрута:
Вместо использования массива вы можете использовать сцепку метода PHP middleware () с определением маршрута:
При назначении посредника вы можете указать полное имя класса:
Группы посредников
Группы посредников могут быть назначены на маршруты и действия контроллера с помощью того же синтаксиса, что и для одного посредника. Группы посредников просто делают проще единое назначение нескольких посредников на маршрут:
Параметры посредника
Посредник terminable
Комментарии (5)
Действительно сбивает заголовок «Посредник «до» и «после»» а после него
PHP class BeforeMiddleware
.
PHP class AfterMiddleware
.
У меня возникло недопонимание которое решилось после прочтения комментариев.
Middleware (промежуточное ПО)
Вы можете запустить код перед и после вашего обработчика в приложении Slim, чтобы манипулировать объектами Request и Response по своему усмотрению. Это называется промежуточное ПО. Зачем это делать? Возможно, вы хотите защитить свое приложение от подделки межсайтовых запросов. Возможно, вы хотите аутентифицировать запросы до запуска вашего приложения. Промежуточное программное обеспечение идеально подходит для этих сценариев.
Что такое промежуточное ПО?
Промежуточное ПО реализует интерфейс PSR-15:
Как работает промежуточное ПО?
Различные фреймворки используют промежуточное ПО по-разному. Slim добавляет промежуточное ПО в виде концентрических слоев, окружающих ваше основное приложение. Каждый новый слой промежуточного ПО окружает любые существующие слои промежуточного ПО. Концентрическая структура расширяется наружу по мере добавления дополнительных слоев промежуточного ПО.
Последний добавленный слой промежуточного ПО выполняется первым.
Когда вы запускаете приложение Slim, объект Request пересекает структуру промежуточного программного обеспечения извне. Сначала они вводят самое внешнее промежуточное ПО, затем следующее внешнее промежуточное ПО (и т.д.), Пока в конечном итоге не достигают обработчика приложения Slim. После того как приложение Slim обрабатывает соответствующий маршрут, результирующий объект Response выходит из приложения Slim и пересекает структуру ПО в обратном порядке. В завершение конечный объект Response выходит из самого внешнего промежуточного ПО, сериализуется в сырой HTTP-ответ и возвращается HTTP-клиенту. Вот схема, которая иллюстрирует поток процесса промежуточного программного обеспечения:
Как писать промежуточное ПО?
Пример промежуточного ПО как анонимная функция.
Пример промежуточного ПО как вызываемый класс.
Чтобы использовать эти классы в качестве промежуточного ПО, вы можете использовать цепочку вызовов метода add(new ExampleMiddleware()); вашего объекта Slim или объектов Route, возвращаемых методами get(), post(), put(), patch(), delete(), options(), any() или group(), как в приведенном ниже коде.
Как добавлять промежуточное ПО?
Вы можете добавить промежуточное ПО в приложение Slim, в отдельный маршрут приложения Slim или в группу маршрутов. Все сценарии принимают одно и то же промежуточное программное обеспечение и реализуют один и тот же интерфейс промежуточного программного обеспечения.
Промежуточное ПО приложения
Промежуточное ПО приложения вызывается для каждого входящего HTTP-запроса не зависимо от маршрута. Добавьте промежуточное ПО приложения с помощью метода add() экземпляра приложения Slim. В этом примере добавлен пример промежуточного программного обеспечения Closure :
Это вывело бы это тело ответа HTTP:
Промежуточное ПО маршрута
Это вывело бы это тело ответа HTTP:
Промежуточное ПО групп маршрутов
В дополнение ко всему, группы маршрутов, определяемые методом group() тоже позволяют использовать промежуточное ПО для всех маршрутов группы. Для добавления промежуточного ПО группе, нужно вызвать метод add() объекта, возвращаемого методом group().
При запросе GET /utils/date будет выведена примерно такая строка.
Посещение /utils/time выведет что-то такое:
Но посещение / (корня домена), приведет к следующему выводу, так как промежуточное ПО не было назначено:
Передача переменных из промежуточного ПО
Установка переменной в промежуточном ПО:
Получение переменной в обработчике:
Поиск доступного промежуточного программного обеспечения
Возможно, вы уже нашли классы промежуточного ПО PSR-15, которые удовлетворяют ваши потребности. Вот несколько неофициальных списков для поиска:
Middleware и возможности Pipeline в Laravel
Laravel — это поистине большая и сложная система, которая старается решить большинство бытовых задач веб разработчика максимально элегантным способом и собрать в себе как можно больше инструментов и, что очень важно — с как можно более человеческим интерфейсом.
И сегодня речь пойдет об одном из таких инструментов, а точнее о его использовании и реализации со стороны программиста. Отсутствие полноценной документации, а также отсутствие русскоязычных статей и очень малое количество статей иностранных — подтолкнуло меня к решению раскрыть некую завесу тайны об этой интересной возможности фреймворка и выбору этой темы в качестве моей первой статьи на Хабре.
Middleware
В этой статье предполагается, что читатель уже знаком с базовым использованием этого функционала фреймворка, поэтому долго останавливаться на этом пункте не буду.
Из коробки Laravel предоставляет нам достаточно мощный функционал фильтрации входящих HTTP запросов к нашему приложению. Речь идет о всеми любимых (или нет) Middleware — с данными классами разработчик на пути освоения Laravel сталкивается достаточно быстро, еще на этапе чтения «The Basics» (Основы) пункта официальной документации, и это не удивительно — Middleware является одним из основных и важнейших кирпичиков, на основе которых строится вся система.
Примерами стандартных юз-кейсов этого компонента в Laravel являются: EncryptCookies/RedirectIfAuthenticated/VerifyCsrfToken, а в пример пользовательской реализации можно привести middleware локализации приложения (установки требуемой локализации на основе определенных данных запроса), перед передачей запроса дальше.
Глубже в бездну
Оставь надежду, всяк сюда входящий
Ну что же, теперь, когда с основными моментами покончено — мы можем углубиться в страшное для многих место — в альфа и омега, начало и конец — в исходники Laravel. Те, кто потянулся сразу закрывать статью — не торопитесь. На самом деле в исходном коде этого фреймворка почти нет чего-то действительно сложного с концептуальной стороны — создатели явно стараются не только создать ясный и удобный интерфейс работы со своим детищем, но и очень стараются делать тоже самое непосредственно на уровне исходного кода, что не может не радовать.
Я постараюсь максимально просто и доступно объяснить концепцию работы Middleware и Pipeline на уровне кода и логики, и постараюсь не углубляться туда — куда не нужно в рамках статьи. Так что, если в комментариях найдутся люди, знающие все строчки исходников наизусть — попрошу воздержаться от критики моего поверхностного повествования. Но любые рекомендации и исправления неточностей — лишь приветствуются.
Middleware — по ту сторону баррикад
Я верю, что изучение чего бы то ни было всегда дается проще, когда предоставляются хорошие примеры. Поэтому изучить этого таинственного зверя под именем Pipeline я предлагаю нам с вами вместе. Если действительно найдутся такие храбрецы — то перед дальнейшим чтением нам потребуется установить пустой проект Laravel версии 5.7 — версия обусловлена лишь тем, что она последняя на момент написания статьи, всё перечисленное должно быть идентично как минимум до версии 5.4. Те же, кто хочет просто узнать суть и выводы статьи — можете смело пропускать эту часть.
Что может быть лучше, чем изучение поведения какого-либо компонента, кроме как не изучение поведения уже встроенного в систему? Возможно что-то и может, но мы обойдемся без излишних усложнений и начнем наш разбор со стандартного Middleware — а именно с самого простого и понятного из всей банды — RedirectIfAuthenticated:
В любом классическом middleware классе существует главный метод, который непосредственно и должен обработать запрос, и передать обработку следующему в цепочке — в нашем случае — это метод handle. В этом конкретном классе обработка запроса достаточно проста — «если пользователь авторизован — то перенаправить его на главную страницу и, тем самым, прекратить выполнение цепочки».
Если мы посмотрим на регистрацию этого Middleware в app/Http/Kernel.php, то мы увидим, что он зарегистрирован в ‘route middleware’. Чтобы нам узнать как же система работает с этим middleware — перейдем в класс, от которого наш app/Http/Kernel наследуется — а наследуется он от класса Illuminate\Foundation\Http\Kernel. На данном этапе мы с вами непосредственно открываем врата в ад исходный код нашего фреймворка, а точнее — в самую важную и основную его часть — в ядро работы с HTTP. Кстати, кому интересно — Laravel базируется на многих компонентах Symfony, конкретно в этой части — на HttpFoundation и HttpKernel.
Определение и реализация наших middleware в конструкторе ядра происходит следующим образом:
Код достаточно простой и понятный — для каждого middleware в массиве мы регистрируем его с алиасом/индексом в нашем роутере. Сами методы aliasMiddleware и middlewareGroups нашего Route класса — это простое добавление middleware в один из массивов объекта роутера. Но это не входит в контекст статьи, поэтому пропустим данный момент и двинемся дальше.
Что нас действительно интересует, так это метод sendRequestThroughRoute, дословно переводящийся, как отправитьЗапросЧерезРоут:
В качестве параметра данный метод получает запрос. На данном моменте нам следует снова заглянуть в код нашего RedirectIfAuthenticated. В методе handle нашего middleware мы тоже получаем запрос, эта заметка нам понадобится немного позже.
Код выше имеет очень понятный и читаемый интерфейс — «Трубопровод», который отправляет запрос через каждый из зарегистрированных middleware, а затем «передает» его в роутер. Прелестно и замечательно. Я думаю на этом этапе мы не будем пытаться декомпозировать данный участок кода дальше, я лишь вкратце опишу роль этого участка во всей системе:
Перед попаданием запроса в ваш контроллер — проходит достаточно много действий, начиная от простого парсинга самой url, и заканчивая инициализацией класса Request. Middleware в этой цепочке действий также участвует. Непосредственно классы middleware реализуют (почти) паттерн проектирования Цепочка обязанностей или Chain of Responsibility, таким образом каждый конкретный класс midleware — это лишь звено в этой цепочке.
Выше мы не просто так вернулись в наш изначально рассматриваемый класс RedirectIfAuthenticated. Запрос «циркулирует» по цепи, в том числе он проходит и через все, требуемые для роута middleware. Этот момент поможет нам с работой со своими собственными звеньями своей собственной цепи, об этом дальше.
Pipeline — канализация нашего приложения
Один из примеров реализации Pipeline мы видели выше. Но целью статьи было не только объяснение работы этого компонента на уровне интеграции с Laravel, а и объяснение базового принципа работы с этим классом в нашем собственном коде.
Сам класс можно найти по его полному определению с неймспейсом:
Применений данному компоненту может быть достаточно много, в зависимости от конкретной задачи, которую вам требуется решить, но одной из самых очевидных мотиваций является требование создания своей собственной цепи обработчиков запроса, которая не вмешивается в процессы всей системы и определяется исключительно на уровне вашей бизнес логики. Также интерфейс класса имеет достаточный уровень абстракции и имеет достаточную для реализации разного вида очередей функциональность.
Пример реализации в Laravel
Реализуем максимально простую и отдаленную от реальности цепочку запросов. В качестве данных мы будем использовать строку » HELLO WORLD», и с помощью двух обработчиков мы сформируем из нее строку «Hello User». Код намеренно упрощен.
Перед непосредственной реализацией нашей собственной «Трубы», нам нужно определить элементы этой трубы. Элементы пишутся по аналогии с middleware:
Затем мы создаем «трубопровод», определяем что за данные мы хотим по нему отправить, определяем через какую коллекцию обработчиков мы хотим эти данные отправить, а также определяем callback, который получает в качестве аргумента наши данные, пройденные через всю цепочку. В том случае, когда данные на протяжении цепочки у нас остаются неизменными — часть с callback’ом можно опустить:
Также, если у вас есть желание или потребность определить свой собственный метод в обработчиках, интерфейс Pipeline предоставляет специальный метод via(‘method_name’), тогда обработка цепи может быть написана таким образом:
Непосредственно данные, которые мы проводим через обработчики — могут быть абсолютно любыми, как и взаимодействие с ними. Тайп хинтинг и установка типа возвращаемого в цепочке объекта поможет избежать ошибок с целостностью данных.
Заключение
Laravel предоставляет большое количество встроенных классов, и гибкость многих из них позволяет с достаточной простотой вести разработку чего-то сложного. В этой статье была рассмотрена возможность создания простых очередей для запросов на основе встроенного в Laravel класса Pipeline. Реализации этого класса в конечном коде могут быть абсолютно разными, а гибкость этого инструмента позволяет избавиться от многих лишних действий при построении определенных алгоритмов.
Как конкретно использовать данную возможность фреймворка — зависит от поставленных перед вами задач.
Middleware
Вы можете запускать код до и после вашего Slim-приложения, чтобы управлять объектами Request and Response по своему усмотрению. Это называется middleware (промежуточным программным обеспечением). Зачем вам это делать? Возможно, вы хотите защитить свое приложение от подделки межсайтовых запросов. Возможно, вы хотите аутентифицировать запросы перед запуском приложения. Middleware идеально подходит для этих сценариев.
Что такое middleware?
Технически говоря, middleware является вызываемым которое принимает три аргумента:
Как работает промежуточное программное обеспечение (middleware)?
Различные структуры используют промежуточное ПО по-разному. Slim добавляет промежуточное ПО как концентрические слои, окружающие ваше основное приложение. Каждый новый слой промежуточного программного обеспечения окружает любые существующие уровни промежуточного программного обеспечения. Концентрическая структура расширяется наружу, когда добавляются дополнительные слои промежуточного слоя.
Последний добавленный слой промежуточного программного обеспечения является первым, который будет выполнен.
Когда вы запускаете приложение Slim, объекты Request and Response пересекают структуру промежуточного программного обеспечения извне. Сначала они вводят самое внешнее промежуточное ПО, а затем следующее внешнее самое промежуточное ПО (и т. Д.), пока они в конечном итоге не прибудут к самому Slim-приложению. После того, как приложение Slim отправляет соответствующий маршрут, результирующий объект Response выходит из приложения Slim и пересекает структуру промежуточного программного обеспечения изнутри. В конечном итоге конечный объект Response выходит из самого промежуточного ПО, сериализуется в исходный HTTP-ответ и возвращается клиенту HTTP. Вот диаграмма, иллюстрирующая поток процесса промежуточного программного обеспечения:
Как написать промежуточное программное обеспечение?
Пример замыкание middleware.
Пример middleware замыкания.
Пример вызываемого класса middleware
Как добавить middleware?
Вы можете добавить промежуточное программное обеспечение в Slim-приложение, на индивидуальный маршрут Slim или в группу маршрутов. Все сценарии принимают одно и то же middleware и реализуют один и тот же интерфейс middleware.
Application middleware
Для каждого входящего HTTP-запроса вызывается middleware. Добавьте промежуточное программное обеспечение приложения с помощью add() метода экземпляра Slim. В этом примере добавляется пример Closure middleware:
Это вывело бы это тело ответа HTTP:
Route middleware
Это вывело бы это тело ответа HTTP:
Групповое Middleware
В дополнение к общему приложению и стандартным маршрутам, способным принимать middleware, group() функция определения нескольких маршрутов, также позволяет индивидуальные маршруты внутри. Маршрутное групповое middleware вызывается только в том случае, если его маршрут соответствует одному из определенных методов HTTP-запроса и URI из группы. Чтобы добавить промежуточное программное обеспечение в обратном вызове и промежуточное ПО всей группы, можно установить путем цепочки add() после group() метода.
Пример приложения, используя callback middleware в группе обработчиков URL-адресов
При вызове /utils/date метода будет выводиться строка, подобная приведенной ниже
посещение /utils/time будет выводить строку, подобную приведенной ниже
но посещение / (domain-root), должно было бы генерировать следующий результат, поскольку не было назначено middleware
Передача переменных из middleware
Установка переменной в middleware:
Получение переменной в обратном вызове маршрута:
Промежуточное ПО¶
Когда запрос обрабатывается вашим приложением, он поступает из самого удалённого промежуточного программного обеспечения. Каждое промежуточное ПО может делегировать запрос/ответ на следующий уровень или возвращать ответ. Возврат ответа предотвращает просмотр нижних слоёв. Примером этого является AssetMiddleware, обрабатывающий запрос на изображение плагина во время разработки.
Если никакое промежуточное ПО не предпринимает действия для обработки запроса, контроллер вызовет экшен, или будет создано исключение, генерирующее страницу с ошибкой.
Промежуточное ПО (Middleware) является частью нового HTTP-стека в CakePHP, который использует интерфейсы запросов и ответов PSR-7. Поскольку CakePHP использует стандарт PSR-7, вы можете использовать любое промежуточное ПО, совместимое с PSR-7, доступное на The Packagist.
Промежуточное ПО в CakePHP¶
CakePHP предоставляет несколько промежуточных программ для обработки общих задач в веб-приложениях:
Cake\Routing\AssetMiddleware проверяет, обращается ли запрос к теме или файлу активов плагина, например, к CSS, JavaScript или файлу изображения, хранящимся в папке webroot плагина или в папке с соответствующей темой.
Cake\Routing\Middleware\RoutingMiddleware использует Router для анализа входящего URL-адреса и назначения параметров маршрутизации для запроса.
Cake\Http\Middleware\SecurityHeadersMiddleware упрощает добавление заголовков, связанных с безопасностью, таких как X-Frame-Options для ответов.
Cake\Http\Middleware\EncryptedCookieMiddleware даёт вам возможность манипулировать зашифрованными файлами cookie, если вам нужно манипулировать файлом cookie с обфускацией данных.
Cake\Http\Middleware\CsrfProtectionMiddleware добавляет CSRF-защиту в ваше приложение.
Использование промежуточного ПО¶
Промежуточное ПО может применяться в вашему приложении как глобально, так и к отдельным областям маршрутизации.
Добавление промежуточного ПО из плагинов¶
Запросы и ответы PSR-7¶
Промежуточное ПО и новый HTTP-стек построены поверх интерфейсов запроса и ответа PSR-7. В то время как всё промежуточное ПО будет подвержено этим интерфейсам, ваши контроллеры, компоненты и представления не будут зависеть от этих интерфейсов.
Взаимодействие с запросами¶
RequestInterface предоставляет методы взаимодействия с заголовками, методом, URI и телом запроса. Чтобы взаимодействовать с заголовками, вы можете:
Запросы также предоставляют доступ к файлам cookie и загружаемым файлам, которые они содержат:
Запросы содержат объект URI, который содержит методы для взаимодействия с запрошенным URI:
Наконец, вы можете взаимодействовать с „атрибутами“ запроса. CakePHP использует эти атрибуты для переноса специфических параметров запроса. В любом запросе, обрабатываемом CakePHP, есть несколько важных атрибутов:
base содержит базовый каталог для вашего приложения, если он есть.
webroot содержит каталог webroot для вашего приложения.
params содержит результаты сопоставления маршрутов после обработки правил маршрутизации.
Взаимодействие с ответами¶
При изменении ответа важно помнить, что ответы неизменяемы. Вы всегда должны помнить о сохранении результатов любого метода сеттера. Например:
Чаще всего вы будете устанавливать заголовки и тела ответов по запросам:
Создание промежуточного ПО¶
Файлы классов промежуточного ПО должны быть помещены в src/Middleware. Например: src/Middleware/CorsMiddleware.php
Предполагается, что промежуточное ПО реализует протокол промежуточного ПО.
Пока что не формальный интерфейс, Middleware действительно имеет soft-интерфейс или „протокол“. Протокол выглядит следующим образом:
Теперь, когда мы создали очень простое промежуточное ПО, давайте подключим его к нашему приложению:
Добавление заголовков безопасности¶
Слой SecurityHeaderMiddleware позволяет легко применять заголовки, связанные с безопасностью, к вашему приложению. После настройки, промежуточное ПО может применять следующие заголовки к ответам:
Это промежуточное ПО настраивается с использованием свободного интерфейса до его применения к стеку(очереди) промежуточного ПО вашего приложения:
Добавлено в версии 3.5.0: SecurityHeadersMiddleware добавлено в 3.5.0
Промежуточное ПО для шифрования файлов cookie¶
Если в вашем приложении есть файлы cookie, содержащие данные, которые вы хотите обфусцировать, чтобы защитить от вмешательства пользователя, вы можете использовать шифрующее промежуточное ПО CakePHP для шифрования и дешифрования файлов cookie. Данные cookie шифруются через OpenSSL с использованием AES:
Рекомендуется, чтобы ключ шифрования, который вы используете для данных cookie, использовался исключительно для данных cookie.
Алгоритмы шифрования и стиль заполнения, используемые промежуточным ПО для cookie, обратно совместимы с CookieComponent из более ранних версий CakePHP.
Добавлено в версии 3.5.0: EncryptedCookieMiddleware было добавлено 3.5.0
Cross Site Request Forgery (CSRF) Middleware¶
Защита CSRF может применяться ко всему вашему приложению или к конкретным областям. Применяя CsrfProtectionMiddleware к вашему промежуточному стеку, защита CSRF может быть применена ко всему вашему приложению или к конкретным областям:
Параметры могут быть переданы в конструктор промежуточного ПО. Доступные параметры конфигурации:
expiry Как долго должен продолжаться токен CSRF. По умолчанию используется сеанс браузера.
Когда включено, вы можете получить доступ к текущему токену CSRF в объекте запроса:
Добавлено в версии 3.5.0: CsrfProtectionMiddleware добавлено в 3.5.0
Интеграция с FormHelper¶
Защита CSRF и AJAX запросы¶
Добавление нового HTTP-стека в существующее приложение¶
Добавление промежуточного ПО для HTTP, в ваше уже существующее приложение, потребует нескольких изменений в вашем приложении.
Сначала обновите свой webroot/index.php. Скопируйте содержимое файла из скелета скелета приложения.
Создайте config/requirements.php, если он не существует, и добавьте содержимое из скелета приложения.
Как только эти три этапа будут завершены, вы готовы начать повторное внедрение любых фильтров отправки приложений/плагинов в качестве промежуточного программного обеспечения HTTP.
