Авторизация в PHP + MVC, где осуществлять проверку?

Question

[avada kedavra]

Имеется каркас MVC-приложения. Все запросы направляются в index.php, там подключаются файл конфигурации, библиотеки, базовые классы model, view, controller и класс Router, отвечающий за маршрутизацию. Дальше запускается метод Router::start() который непосредственно разбивает URL и вызывает нужный контроллер.
Как правильно реализовать авторизацию? Делать проверку установлена ли сессия в каждом контроллере?
Как-то не изящно получается.

Answer 1

[xskif]

Идеальный вариант - создать middleware слой между контроллером и роутером. Дать возможность подгружать туда middleware классы через конфигурацию или заранее определенную папку. Создать класс который и будет проверять сессию/куки. Обычно вся логика в таких классах лежит в методе 'run'.

Если не хотите усложнять, можете создать ApplicationController, в котором будет базовый функционал для всех контроллеров приложения, например, авторизация, и наследовать все остальные контроллеры от него.

Еще можно добавить авторизацию в качестве RequestInterceptor класса, который так же подключается к контроллеру (лучше к базовому) и реагирует на прописанные события контроллера. Подписываете перехватчик на beforeAction и проводите авторизацию. Последний способ больше для RESTful приложений.

Comments

[avada kedavra]

>Если не хотите усложнять, можете создать ApplicationController, в котором будет базовый функционал для всех контроллеров приложения, например, авторизация, и наследовать все остальные контроллеры от него.
Пожалуй, пока на этом остановлюсь, спасибо.

Answer 2

[Сергей Протько]

Читаем про HTTP Middelware, request-response фреймворки, не зацикливаемся на MVC. В итоге влоу выходит таким:

Предположим что у нас есть интерфейс Kernel содержащий метод handle, который на вход принимает Request и на выход выдает Response. Далее...

- Собираем Request из глобальных переменных
- Передаем его в херню реализующую Kernel
- за счет применение паттерна адаптер можно сделать много вложенных друг в дружку реализаций интерфейса Kernel. Одна реализация ресолвит рауты, вторая - авторизацию хэндлит, третья добавляет CORS... и самая внутренняя уже вызывает контроллер вашего так называемого MVC каркаса.

Профит - все можно покрыть тестами, все удобно скейлится, есть кучи готовых реализаций. В конце концов есть PSR-7.

В любом случае аутентификацию надо делать во фронт-контроллере, а авторизацию - уже могут быть варианты.

Comments

[xskif]

>> за счет применение паттерна адаптер можно сделать много вложенных друг в дружку реализаций интерфейса

Может Вы имели ввиду "декоратор"?

[Сергей Протько]

xskif: не совсем. Если обертка что-то меняет во входных данных что бы адаптировать для внутренней части - это все же адаптер нежели декоратор.

[xskif]

Сергей Протько: Да что Вы. Адаптер адаптирует реализацию под требуемый интерфейс через композицию адаптируемого объекта, в то время как декоратор оборачивает объекты с идентичным интерфейсом для изменения или дополнения поведения методов.

Адаптер не меняет поведение, декоратор же меняет или дополняет поведение вложенных объектов. Как раз Ваш случай.

[Сергей Протько]

xskif: бог с вами. Не в этом суть. Совсем не в этом.

Вообще главное отличие адаптера от декоратора - если убрать декоратор - приложение продолжит работать как ни в чем не бывало. Так, если ваш мидлвэр реализует десериализацию объектов или еще какую-нибудь сатану связанную с данными запроса (ту же маршрутизацию) - то если его убрать - все упадет. А вот при кешировании скажем - там да, декорация происходит.

[xskif]

Сергей Протько: на лицо подмена понятий. Middleware не обязательно быть адаптером, а Вы его сравниваете. Но, я соглашусь, если убрать адаптер из приложения - то оно, скорее всего, упадет, потому что интерфейс не соответствует. А вот декораторы должны быть взаимозаменяемы. От сюда вернемся к Вашему ответу. Вы предложили адаптерам делать то, для чего они не предназначены, оборачивать другие адаптеры бесконечное количество раз, называя декораторы адаптерами. Мне сразу вспоминается статья про ТТУКи. Собственно, поэтому я и придрался.

Middleware не обязательно является адаптером, более того, в большинстве случаев это совсем не адаптеры, скорее Chain of Responsibility. Для того они и подключаются через конфигурацию, чтобы добавить логику в Application Logic Layer, но их там может и не быть и приложение запустится, просто без той же аутентификации и авторизации.

[Сергей Протько]

xskif: Соглашусь.

Answer 3

[Дмитрий]

Нужен базовый контроллер, в котором будут установлены все необходимые параметры. От этого контроллера наследуются контроллеры приложений

Answer 4

[Mike]

в моделе