Autorisation
Statut
Document de cadrage backend — v1.0 — relu le 2026-05-11.
Rôle
L'autorisation décide si un utilisateur authentifié peut effectuer une action.
Elle doit rester côté backend et ne pas être déléguée aux frontends.
État actuel visible
Le projet contient :
- policies sur plusieurs modules ;
- middleware
ensure.admin; - middleware
asso.access; - middleware
mairie.access; - middleware
device.tokenpour PlayLoop ; - vérifications d'ownership, notamment via
user_acteurs; - routes protégées par
auth:sanctum.
Niveaux d'autorisation
| Niveau | Exemple |
|---|---|
| Authentifié | Accès à /auth/me, actions utilisateur. |
| Administrateur | Routes admin, settings sensibles. |
| Propriétaire d'acteur | Gestion d'un acteur ou de ses documents. |
| Mairie | Gestion alertes, services et publications mairie. |
| Association | Gestion membres, cotisations, projets AssoSuite. |
| Device | Lecture playlist PlayLoop via token device. |
Policies
Les policies doivent être utilisées pour les décisions liées à un modèle :
- modifier un acteur ;
- supprimer un contenu ;
- gérer des documents ;
- modérer une publication ;
- accéder à une ressource appartenant à un acteur.
Middlewares
Les middlewares conviennent aux vérifications transverses :
- utilisateur authentifié ;
- source applicative ;
- rôle admin ;
- accès mairie ;
- accès association ;
- token device.
Principes
- Refuser par défaut si le droit n'est pas clair.
- Vérifier côté backend à chaque mutation.
- Ne pas exposer une action frontend si elle sera refusée, mais ne pas s'y fier.
- Renvoyer des erreurs cohérentes : 401, 403, 422.
- Garder les règles sensibles testées.
Points à clarifier
- Matrice complète des droits par module.
- Autorisations entre applications.
- Règles exactes de modération locale.
- Droits premium vs droits métier.
- Droits IA et quotas associés.