Forge fournit les briques de sécurité suivantes dans core/security/ :
| Brique | Fichier | Rôle |
|---|---|---|
| Sessions | session.py |
Création, rotation, expiration, stockage en mémoire |
| Hachage | hashing.py |
PBKDF2-HMAC-SHA256, rate limiting sur /login |
| Décorateurs | decorators.py |
@require_auth, @require_csrf, @require_role |
| Autorisation | rbac.py |
@require_permission, has_permission, get_request_permissions, make_can |
| Middleware | middleware.py |
AuthMiddleware, CsrfMiddleware |
| RBAC | rbac.py |
Modèles Role, Permission, normalisation, validation |
La documentation complète du RBAC Forge (rôles, permissions, décorateurs, helper Jinja, génération CRUD, chaîne de confiance) se trouve dans RBAC — Contrôle d'accès.
from core.security.rbac import require_permission, has_permission, make_can
# Protéger une route serveur
@staticmethod
@require_permission("posts.edit")
def edit(request): ...
# Vérifier une permission dans le code
if has_permission(request, "posts.edit"):
...
# Helper Jinja — injecté automatiquement par BaseController.render(request=request)
# {% if can("posts.edit") %} ... {% endif %}Injecter les permissions après authentification :
utilisateur = {
"UtilisateurId": row["id"],
"Login": row["login"],
"roles": ["admin"],
"permissions": ["posts.edit", "posts.delete", "users.view"],
}
nouveau_id = authentifier_session(session_id, utilisateur)- Pas d'ORM complet pour les permissions.
- Pas de gestion automatique des politiques (
deny by defaultreste à l'application). - Pas de cache de permissions distribué.
- Pas de hiérarchie de rôles automatique.
- Pas de liaison
user ↔ rôle ↔ permissiondans le core (appartient à l'application).