Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Здравствуйте!
Существует БД на PostgreSQL, со своей собственной системой хранения пользователей и их ролей. Требуется сделать веб-приложение, для работы с этой БД.
Ранее у меня был опыт работы во фреймворке Kohana, но он сдох, поэтому я выбрал Laravel.
Этот опыт со мною играет злую шутку. Начал делать так, как дела всегда. Создаю контроллер-предка, в котором выполняю все однотипные действия, присущие унаследованным контроллерам.
Обычно я в этом предке проверял, аутентифицирован ли пользователь, и если нет, редиректил его на страницу логина. Таким образом все остальные страницы оказывались недоступны неаутентифицированному пользователю.
Здесь я пошёл этим же путём. Добавил в уже существующий контроллер Controller.php нужный функционал и в теле конструктора делают редирект к нужному мне адресу:
public function __construct()
{
// тут какой-то код
if (!$this->IsAuth()) return redirect('/user');
}Но эта директива ни к чему не приводит. Просто не работает.
Вчитался в маны. Вычитал, что я могу передать управление в посредник. Сделал свой посредник, написал тестовую функцию, зарегистрировал его в Kernel.php
public function handle(Request $request, Closure $next)
{
if (true) return redirect('/user');
return $next($request);
}Прописал роутинг
Route::get('test', [MainController::class, 'test'])->middleware('CheckAuth');На выходе браузер ругается: ERR_TOO_MANY_REDIRECTS
Подскажите, что я делаю не так и как можно реализовать редирект?
Спасибо!
Не в сети
Подскажите, что я делаю не так и как можно реализовать редирект?
Если честно , я не понял какой велосипед Вы пытаетесь построить , но на этом же форуме в разделе Документация , почитайте раздел Аунтефикация. Ссылка ,если чО. https://laravel.ru/docs/v5/authentication
Изменено DzonyBB (02.07.2021 19:05:36)
Не в сети
Писарь 
Конструктор контроллера выполняется ДО того как обрабатываются куки и происходит идентификация пользователя. Поэтому проверка не работает.
Если я правильно понял задумку, то вам надо воспользоваться controller middleware. Объявление middleware не означает что её код выполнится прямо в этом месте и в этот момент. Мы таким образом помещаем проверку в очередь (стек) посредников, которые выполнятся позже конструктора, но перед обращением к методу-экшену маршрута.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
почитайте раздел Аунтефикация
Мир не завязан на шаблонных моделях из коробки. БД УЖЕ существует и прекрасно работает. Никто не собирается заниматься переделками под Laravel. Требуется прикрутить веб-морду к уже рабочей базе, а не рихтовать рабочую базу под модуль Auth одного из фреймворков. Кстати, в проекте используется сырой SQL.
Конструктор контроллера выполняется ДО того как обрабатываются куки и происходит идентификация пользователя.
Как я понимаю (если не прав, поправьте), ядро фреймворка получает запрос, смотрит в конфиг роутинга и создаёт нужный класс. При создании класса вызывается конструктор, если он есть в наличии. Мне не совсем понятно, почему я могу получить доступ к сессии из любого метода класса, а из конструктора не могу.
Кстати, я действительно воспользовался middleware.
Не в сети
Писарь
- Мне не совсем понятно, почему я могу получить доступ к сессии из любого метода класса, а из конструктора не могу.
Потому что так устроен стек обработки запроса. Сначала сначала выясняется конечная точка маршрута — метод контроллера, создается экземпляр объекта этого контроллера. Потом вызываются мидлвары в прямом проходе чтобы иметь возможность поработать с запросом. И на вершине стека срабатывает обработчик роута, создается ответ на запрос. Затем мидлвары получают управление в обратном порядке, чтобы иметь возможность поработать с объектом ответа.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
Потому что так устроен стек обработки запроса.
Ага, т.е. просто потому, что фреймворк так работает.
создается экземпляр объекта этого контроллера
и при создании объекта ему ничего не передаётся? Что-то вроде new Class();
Просто в Кохане при создании класса ему передавался $request и $response, а к сессии я получал доступ через Session::instance();
Хотя, как я понимаю, мне никто не запрещает использовать $_SESSION, кроме понимания, что это будет слишком костыльно и выбиваться из концепции фреймворка.
Правильно ли я понимаю, что в случае с Laravel правильным подходом видится именно использование посредников (middleware), в котором мне будет доступна session?
И разрешите ещё глупые вопросы: в посредниках доступен фасад DB, или есть иные способы достучаться до базы данных? Само собой pg_connect никто не отменял, но это опять выглядит костыльно.
Спасибо!
Не в сети
Писарь Ларавель использует симфоневский Http Foundation, поэтому вероятно сходное поведение будет и в множестве других мест: новые версии PHPBB, Drupal и др.
При создании сервиса в т.ч. контроллера можно указать класс или интерфейс для инъекции. Это тема большая, не буду пытаться чему-то учить.
Если этот код не увидит никто кроме тебя, то ради бога, используй инородные сущности. Иначе не надо ))) не провоцируй хейт.
Да, правильно через посредников.
DB будет доступен. Также как и классы-модели. Будет всё доступно, кроме объектов, порождаемых в middleware.
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
не буду пытаться чему-то учить.
Ну вот. А я только собрался поучиться.
Не в сети
Для тех, кто еще не разобрался:
return redirect('/user')->send();->send()
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)