[Перевод] Простой контроль доступа ACR в Laravel 10 (инструкция шаг за шагом)17.04.2023 08:31

Что происходит в результате:

Пример 2

Давайте попробуем проверить разрешение в самом контроллере.

Добавим в файл routes\web.php:

Route::get('/example2', [Example2Controller::class, 'show']);

Исходник файла …Example2Controller.php:

toArray(), 200);
    }
}

Пример, как можно использовать фасад Laravel Gate.

Пример 3

Этот пример очень похож на предыдущий, но с использованием параметра опции.
Добавим в файл routes\web.php:

Route::any('/example3/{frm}', [Example3Controller::class, 'update']);

Исходник файла …Example3Controller.php:

value);

        $user = Auth::user();
        switch ($frm)
        {
            case(UserProfileFormEnum::Name):

                if($request->name) $user->fill( $request->only(['name']) );

            break;
            case(UserProfileFormEnum::Password):

                if($request->password) $user->password = Hash::make($request->password);

            break;
            case(UserProfileFormEnum::Email):

                $validator = Validator::make($request->all(), [
                    'email' => 'required|email',
                ]);
                if ($validator->fails()) abort('403', $validator->messages());

                $user->email = $request->email;

            break;
        }

        return Response::json($user->save(), 200);
    }
}

Почему возникает такое поведение и в чем отличие поля »Option» от стандартного определения правил?

Стоит отметить, что поле «Option» не предназначено не для правила, а к самим разрешением.
Это сделано для того, чтобы позволить создавать несколько разрешений в рамках одного правила.
Например, можно получить отдельный список записей по ID, к которым необходимо организовать доступ, не создавая отдельных таблиц или полей.

Пример 4

В этом примере мы воспользуем встроенную функцию $this→authorizeResource (), которая поставляется вместе с функцией ресурсов (resource). Эта функция очень удобна, так как автоматически создает проверки для следующих правил: «viewAny», «view», «create», «update» и «delete».
Добавим в файл routes\web.php:

Route::apiResource('example4', Example4Controller::class)->parameters([
    'example4' => 'news'
]);

Исходник файла …Example4Controller.php:

authorizeResource(News::class, 'News');
    }

    /**
     * Display a listing of the resource.
     */
    public function index()
    {
        return Response::json(News::all());
    }

    /**
     * Store a newly created resource in storage.
     */
    public function store(Request $request)
    {
        $news = News::create($request->toArray());

        return Response::json($news->id, 201);
    }

    /**
     * Display the specified resource.
     */
    public function show(News $news)
    {
        return Response::json($news->toArray());
    }

    /**
     * Update the specified resource in storage.
     */
    public function update(Request $request, News $news)
    {
        $news->fill($request->toArray());

        return Response::json($news->save);
    }

    /**
     * Remove the specified resource from storage.
     */
    public function destroy(News $news)
    {
        return Response::json($news->delete());
    }
}

Пример 5

В предыдущем примере мы использовали глобальные правила, что не очень удобно. Чтобы это исправить, мы можем создать trait который позволит создавать правила для каждого контроллера отдельно.

Исходник файла App\Http\Traits\GuardedController.php:

 'viewAny']
     *
     * @var string[]
     */
    //abstract protected $guardedMethods = [];

    /**
     * Do not automatically scan all available methods.
     *
     * @var bool
     */
    //abstract protected $disableAutoScanGuard = true;

    /**
     * List of resource methods which do not have model parameters.
     * @example ['index']
     *
     * @var string[]
     */
    //abstract protected $methodsWithoutModels = ['index'];

    /**
     * Get the map of resource methods to ability names.
     *
     * @return array
     */
    protected function resourceAbilityMap()
    {
        if (empty($this->disableAutoScanGuard)) {
            $methods = array_diff(
                get_class_methods($this),
                get_class_methods(Controller::class)
            );
            $map = array_combine($methods, $methods);
        } else {
            $map = [];
        }

        $map = array_merge($map, parent::resourceAbilityMap());
        $map = array_merge($map, $this->guardedMethods??[]);

        // Replace name for class App\Http\Controllers\Examples\Example1Controller
        // to guard prefix "Examples.Example1."
        $name = $this->getClassNameGate();

        // Replace standard rule "viewAny" to "Examples.Example1.viewAny"
        foreach ($map as &$item) {$item = $name.$item;}
        unset($item);

        return $map;
    }

    /**
     * Get the list of resource methods which do not have model parameters.
     *
     * @return array
     */
    protected function resourceMethodsWithoutModels()
    {
        $base = parent::resourceMethodsWithoutModels();

        return array_merge($base, $this->methodsWithoutModels??[]);
    }

    /**
     * Get name off class witch namespace for guard
     *
     * @param string|null $action
     * @return string
     */
    protected static function getClassNameGate(?string $action = null): string
    {
        // Replace name for class App\Http\Controllers\Examples\Example1Controller
        // to guard prefix "Examples.Example1."
        $name = str_replace([
            'App\\Http\\Controllers\\',
            '\\',
            'Controller'
        ], [
            '', '.', '.'
        ], static::class);

        return $name.$action;
    }
}

Контроллер и его пример остаются точно такими же, как в предыдущем примере.
Только добавляется трейт (файл …Example5Controller.php):

authorizeResource(News::class, 'News');
    }
...

Просмотр уже дает другую ошибку:

Таким образом, с минимальными изменениями в существующем коде
можно легко включить возможности динамического управления доступом.

Пример 6

Ниже представлен достаточно простой пример, похожий на второй.
Здесь присутствует использование »магиеской» проверки.
Добавим в файл routes\web.php:

Route::any('/example6/{news}', [Example6Controller::class, 'update']);

Исходник файла …Example6Controller.php:

fill($request->toArray());

        return Response::json($news->save?1:0);
    }
}

Давайте внимательнее рассмотрим это. Если у нас есть правило »example6.update.self»,
нам необходимо проверять правило »example6.update», система сама добавит ».self»,
если есть объект записи для проверки внутри ACR.

Другии словами работа ACR будет выглядеть так:

if (
    'example6.update' === $ability
    && Gate::allows('example6.update.self')
    && $user->id === $news->user_id
) {
    return true;
}

Кроме того, стоит отметить, что если мы не проверяем пользователя, а другую модель, например, модератор.
ACR отслеживает это, и проверка будет выглядеть, примерно так, внутри системы:

$moderator = App\Models\Moderator::find('...');
if (
    'example6.update' === $ability
    && Gate::forUser($moderator)->allows('example6.update.self')
    && $moderator->uuid === $news->moderator_uuid
) {
    return true;
}

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

Пример 7

Хотя это не ABAC, необходимая функциональность контроля доступа на основе атрибутов, может быть достигнута, путем механизма политик Laravel.

Все предыдущие примеры сосредоточены на проверке доступа к контроллеру, но мы можем использовать тот же подход в »Policy» для реализации контроля доступа через атрибуты со всеми их вариациями.
Для этого необходимо сгенерировать политику для нашей модели:

php artisan make:policy NewsPolicy –model=News

Исходник файла …NewsPolicy.php:

can('Example7News.allowedEditLast24Hours', $news)
            && stripos($user->name, 'author') !== false
            && ($news->created_at->isToday() || $news->created_at->isYesterday())
        ) {
            return true;
        }
        return null;
    }
}

После этого необходимо обновить значение $policies в классе AuthServiceProvider, как написано ниже:

protected $policies = [
    News::class => NewsPolicy::class,
];

Теперь проверим политику в контроллере:
Исходник файла …Example7Controller.php:

authorize('availableUpdateOnSomeTime', $news);

        return Response::json($news->toArray());
    }
}

Таким образом, теперь мы можем проверять не только правила индивидуально, но также проверять атрибуты модели или пользователя.

Важно отметить, что если вы добавите правило »availableUpdateOnSomeTime» и разрешение для пользователя, то политика не будет проверена.

Финальный пример

По умолчанию интерфейс AccessUi не включает проверку уровня предоставленного доступа.
Чтобы исправить это, мы можем создать прокси-контроллер, который будет проверять все разрешения перед любой манипуляцией с данными.

Сначала отключим стандартные маршруты AccessUi.
Для этого нужно отредактировать файл config/accessUi.php:

    /**
     * Panel Register
     *
     * This manages if routes used for the admin panel should be registered.
     * Turn this value to false if you don't want to use admin panel
     */
    'register' => false,

Затем мы создадим 2 контроллера:»UserRulesController» и »UserProfileController», которые используют трейт »RunsAnotherController» для запуска других контроллеров от AccessUi.
Также добавим представление в файлах »user-rules.blade.php» и »user-profile.blade.php».
Файлы немного длинные для статьи, но их можно просмотреть отдельно в репозитории.

Как результат, у нас будет отдельные страницы в нашем стиле с проверкой прав доступа

Страница профиля авторизованного пользователя:

Список правил и только ролей (скрыт список пользователей и групп):

Заключение, с помощью »wnikk/laravel-access-rules» (ACR, ACL, RBAC) в проекте на Laravel — можно создать, мощный способ обеспечения доступа, пользователей только к тем ресурсам, к которым они авторизованы.

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

Используя Access-Control-Rules, разработчик может добавлять возможности динамического контроля доступа в свои приложения Laravel с минимальными изменениями кода, обеспечивая безопасность и легкость обслуживания приложения.

© Habrahabr.ru