Где обычно размещается логика авторизации в приложении?

Логика авторизации (проверка прав доступа) обычно выносится в отдельный слой, часто реализуемый как Middleware (в конвейере запросов) или Сервис/Интерцептор. Это позволяет централизовать проверки и избежать дублирования кода в каждом контроллере.

Типичные места размещения:

1. Middleware/Фильтр: Проверяет каждый входящий запрос перед передачей в контроллер. Это идеальное место для проверки JWT-токенов, ролей пользователя.

   // Laravel-style Middleware
   class CheckAdminRole
   {
       public function handle($request, Closure $next)
       {
           $user = Auth::user();
           if (!$user || !$user->hasRole('admin')) {
               abort(403, 'Forbidden');
           }
           return $next($request);
       }
   }
   // Маршрут с применением middleware
   Route::get('/admin/dashboard', [AdminController::class, 'index'])->middleware('auth', 'role:admin');

2. Сервис авторизации (Policy/Guard): Содержит бизнес-логику проверок. В Laravel это Policies, в Symfony — Voters.

   // Policy в Laravel
   class PostPolicy
   {
       public function update(User $user, Post $post): bool
       {
           // Пользователь может редактировать только свои посты
           return $user->id === $post->user_id;
       }
   }
   // Использование в контроллере
   $this->authorize('update', $post);

3. Аннотации/Атрибуты: В современных фреймворках проверки можно декларативно описывать прямо над методами контроллера.

   // Symfony с атрибутами
   #[IsGranted('ROLE_ADMIN')]
   #[IsGranted('POST_EDIT', subject: 'post')]
   public function edit(Post $post): Response { ... }

Ключевой принцип: Логика авторизации должна быть отделена от логики аутентификации (кто вы?) и бизнес-логики. Это повышает безопасность и упрощает тестирование.