Block 6 is COMPLETE. A COMPLETELY open API has become a system that CHECKS identity, DISTINGUISHES roles, and PRECISELY controls access down to INDIVIDUAL records.

What block 6 covered

• Chapter 47: the User entity with UserInterface.
• Chapter 48: the JWT bundle, key pair, automatic password hashing via a state processor.
• Chapter 49: /api/login, two firewalls, obtaining a token.
• Chapter 50: Authorization: Bearer, 401 without/with an expired token.
• Chapter 51: the security attribute, 403 vs. 401, securityMessage.
• Chapter 52: a custom ProjectVoter.
• Chapter 53: wiring up the voter via is_granted() and object.
• Chapter 54: automatically setting the owner field via a state processor.
• Chapter 55: filtering collections by user via a custom state provider.

Project state at the end of block 6

api/
└── src/
    ├── Entity/
    │   ├── Project.php   ← owner, security attributes per 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

Apply it yourself: writing a TaskVoter

As an EXERCISE: transfer the ProjectVoter pattern to Task – a user may edit a task ONLY if they are the OWNER of the RELATED project ($task->getProject()->getOwner()).

What's coming in block 7

The state providers/processors from this block were brought forward PRAGMATICALLY, WITHOUT fully explaining the CONCEPT. Block 7 (chapters 57-66) catches up: the COMPLETE provider/processor system in depth, CUSTOM operations BEYOND the six default types, and the PROMISED complete DTO example from chapter 27 (ProjectSummary WITH a real provider).