Naar de inhoud
Recognized by Laravel Match je project Contact
Projectstructuur en architectuur

Gebruik policies en gates voor autorisatie

Voor het laatst bijgewerkt op:

Introductie

Policies en gates zijn standaardcomponenten binnen Laravel die gebruikt kunnen worden om te bepalen of een actie uitgevoerd mag worden.

Waarom

  • Het stelt je in staat om autorisatielogica op één plek te zetten (in een Policy-class of Service Provider) in plaats van in losse if-statements. Dit voorkomt gedupliceerde code
  • De autorisatiecode is beter herbruikbaar
  • Het ontkoppelt autorisatiecode van businesslogica (separation of concerns)
  • First class citizen binnen Laravel, wat betekent dat het goed onderhouden wordt, en policies en gates kunnen ook in unit tests gebruikt worden.

Geschikt voor

  • Vrijwel elke Laravel-applicatie

Minder geschikt voor

  • Voor kleinere applicaties kan het wat onnodige overhead veroorzaken om zeer strikte policies en gates toe te passen. Het kan dan nuttiger zijn om autorisatie met losse if-statements te regelen

Meer info

Skill

Laravel Boost Skill

Gebruik deze skill om de richtlijn rechtstreeks toe te passen met een AI-assistent.

Use this skill when a Laravel task touches this best practice. It is self-contained so it can be installed independently by Laravel Boost or another agent-skill system.

## Core Guidance

Policies and gates are standard components within Laravel that can be used to determine whether an action may be performed.

## Why It Matters

- It allows you to put authorization logic in one place (in a Policy class or Service Provider) instead of separate if statements. This prevents duplicated code
- The authorization code is more reusable
- It is decoupled authorization code from business logic (separation of concerns)
- First class citizen within Laravel, which means it is well maintained, and policies gates can also be used in unit tests.

## Apply When

- Almost every Laravel application

## Be Careful When

- For smaller applications it can cause some unnecessary government effort to apply very strict policies and gates. It may be more useful to provide authorization with separate if statements

## Canonical Source

- Full best practice: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/project-structure-and-code-architecture/use-policies-and-gates-for-authorization/BEST_PRACTICE.md
- Dutch translation: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/project-structure-and-code-architecture/use-policies-and-gates-for-authorization/translations/nl.md

## Workflow

1. Inspect the user's Laravel code before recommending changes.
2. Identify the narrow rule from this best practice that applies to the task.
3. Prefer Laravel's built-in conventions and documented APIs over custom abstractions.
4. Keep examples focused on this practice; reference other skills or practices when the task crosses boundaries.
5. Verify code changes with the project's available tests, linters, static analysis, or framework checks.

## Review Checklist

- The recommendation is Laravel-specific and grounded in this practice.
- Code examples use realistic Laravel file names, class names, and method names.
- The advice avoids mixing unrelated architecture, deployment, security, or testing topics.
- Related practices are mentioned when useful, but not re-explained in full.
- Dutch output, when requested, keeps framework and API names intact.