Block 6 ist ABGESCHLOSSEN. Aus einer KOMPLETT offenen API ist ein System geworden, das Identität PRÜFT, Rollen UNTERSCHEIDET und Zugriff bis auf EINZELNE Datensätze GENAU steuert.

Was Block 6 behandelt hat

• Kapitel 47: die User-Entity mit UserInterface.
• Kapitel 48: JWT-Bundle, Schlüsselpaar, automatisches Passwort-Hashing über einen State Processor.
• Kapitel 49: /api/login, zwei Firewalls, ein Token erhalten.
• Kapitel 50: Authorization: Bearer, 401 ohne/mit abgelaufenem Token.
• Kapitel 51: das security-Attribut, 403 vs. 401, securityMessage.
• Kapitel 52: ein eigener ProjectVoter.
• Kapitel 53: den Voter über is_granted() und object einbinden.
• Kapitel 54: das owner-Feld automatisch über einen State Processor setzen.
• Kapitel 55: Collections über einen eigenen State Provider nach Nutzer filtern.

Projektstand am Ende von Block 6

api/
└── src/
    ├── Entity/
    │   ├── Project.php   ← owner, security-Attribute pro Operation
    │   ├── Task.php
    │   ├── Tag.php
    │   └── User.php      ← UserInterface, plainPassword
    ├── Security/
    │   └── Voter/
    │       └── ProjectVoter.php
    ├── State/
    │   ├── UserPasswordHasherProcessor.php
    │   ├── ProjectOwnerProcessor.php
    │   └── OwnProjectsCollectionProvider.php
    ├── Filter/
    │   └── MultiFieldSearchFilter.php
    └── DataFixtures/
        └── AppFixtures.php

Selbst anwenden: einen TaskVoter schreiben

Als ÜBUNG: übertragen Sie das ProjectVoter-Muster auf Task – ein Nutzer darf eine Task NUR bearbeiten, wenn er Owner des ZUGEHÖRIGEN Projekts ist ($task->getProject()->getOwner()).

Was in Block 7 kommt

Die State Provider/Processor aus diesem Block wurden PRAGMATISCH VORGEZOGEN, OHNE das KONZEPT vollständig zu erklären. Block 7 (Kapitel 57-66) holt das NACH: das VOLLSTÄNDIGE Provider/Processor-System im Detail, EIGENE Custom-Operations JENSEITS der sechs Standard-Typen, und das VERSPROCHENE vollständige DTO-Beispiel aus Kapitel 27 (ProjectSummary MIT echtem Provider).