Die access_control-Regel aus Kapitel 49 sichert PAUSCHAL den GESAMTEN /api-Bereich – das security-Attribut auf einer Operation erlaubt FEINGRANULARERE, ressourcenspezifische Regeln.

Eine Operation auf eine Rolle beschränken

use ApiPlatform\Metadata\Delete;

#[ApiResource(
    operations: [
        new GetCollection(),
        new Get(),
        new Post(),
        new Put(),
        new Patch(),
        new Delete(security: "is_granted('ROLE_ADMIN')"),
    ],
    // ...
)]

security nimmt einen SYMFONY-EXPRESSION-LANGUAGE-Ausdruck entgegen – is_granted('ROLE_ADMIN') prüft GENAU dieselbe Rolle wie #[IsGranted] in einem klassischen Symfony-Controller.

Das Verhalten testen

curl -k -i -X DELETE https://localhost/api/projects/1 \
  -H "Authorization: Bearer $TOKEN"

HTTP/2 403

{
  "hydra:description": "Access Denied."
}

Status 403 Forbidden – WICHTIG: NICHT 401. Der Token IST gültig (die Identität ist BEKANNT), aber die ROLLE reicht NICHT aus. 401 bedeutet "wer bist du?", 403 bedeutet "ich weiß, wer du bist, aber das darfst du NICHT".

security auf der gesamten Resource

#[ApiResource(
    security: "is_granted('IS_AUTHENTICATED_FULLY')",
    operations: [ /* ... */ ]
)]

security auf RESOURCE-Ebene gilt für ALLE Operationen GLEICHERMASSEN, ZUSÄTZLICH zu ETWAIGEN operation-spezifischen Regeln – BEIDE müssen ERFÜLLT sein.

securityMessage für eigene Fehlermeldungen

new Delete(
    security: "is_granted('ROLE_ADMIN')",
    securityMessage: 'Nur Administratoren dürfen Projekte löschen.',
),

GENAU wie notInRangeMessage bei Constraints (Kapitel 21) ERSETZT securityMessage die generische "Access Denied"-Meldung durch eine SPRECHENDERE, eigene Formulierung.