5a4897921e
Some checks failed
CI / php-lint (push) Successful in 19s
CI / secret-scan (pull_request) Successful in 8s
CI / secret-scan (push) Successful in 10s
CI / static-tests (push) Successful in 30s
CI / php-lint (pull_request) Successful in 19s
CI / auto-merge (push) Has been skipped
CI / static-tests (pull_request) Successful in 30s
CI / auto-merge (pull_request) Failing after 4s
Ferme le finding HIGH de la revue Produits (#17) : le PIN d'action sensible etait verifie sans limitation de tentatives. Conception via panel multi-agents (3 lentilles + synthese + passe adversariale, holds=true) puis revue de l'implementation (holds=true). Dimension du throttle = UTILISATEUR AGISSANT (identite de session, RG-T02), pas l'email cible (contournable par rotation) ni l'IP (collateral sur poste partage). Table dediee pin_throttle (entite 22) STRICTEMENT SEPAREE des compteurs de login (user.failed_login_attempts / login_throttle) : un echec de PIN n'incremente aucun compteur de connexion (pas d'escalade DoS vers le login). - db/migrations/0002_pin_throttle.sql : table cle sur actor_user_id (UNIQUE, FK -> user ON DELETE CASCADE), separee du login. Appliquee a la base dev. - ThrottlePolicy : dimension 'pin' (bornes propres PIN_THROTTLE_*, 30s..300s, plus permissives que le login : controle de dissuasion, residuel Faible). - PinThrottle (nouveau) : isLocked / recordFailure (upsert atomique + backoff, une transaction, miroir d'AuthService) / reset (UPDATE simple). N'ecrit jamais user/login_throttle/audit_log. - PinVerifier::payTimingDecoy : parite de timing du chemin verrouille. - ProductController update/destroy : gate AVANT verification (leurre + 422 generique, pas de pin.failed sous verrou actif = borne anti-flood de l'audit) ; recordFailure sur PIN faux ; reset sur succes, cle sur l'acteur de SESSION. - Docs Merise 21 -> 22 entites : RG-T22 (mlt), entite 22 pin_throttle (mcd/mld/dictionary), couverture MCT 22/22 (mct). - .env.example + docker-compose : PIN_THROTTLE_THRESHOLD/BASE/MAX/WINDOW. - Journal RNCP : docs/journal/2026-06-15--p3-throttle-pin-rg-t22.md. Tests : 188 verts (525 assertions), PHPStan L6 propre. |
||
|---|---|---|
| .. | ||
| migrations | ||
| seeds | ||
| migrate.sh | ||
| README.md | ||
| seed.sh | ||
Base de donnees - migrations & seeds
Transcription executable du MLD (docs/merise/mld.md, 21 tables) vers MariaDB 11.4.
Arborescence
db/
migrations/ migrations SQL versionnees, appliquees dans l'ordre lexicographique
0001_init_schema.sql schema initial : 21 tables, FK, CHECK, index (InnoDB, utf8mb4)
seeds/ donnees de demonstration (a venir : roles/permissions, allergenes, catalogue)
migrate.sh runner de migrations (idempotent)
Appliquer les migrations
bash db/migrate.sh # applique les migrations en attente
bash db/migrate.sh --status # liste l'etat sans rien appliquer
Le runner cible le conteneur wakdo-db et lit les identifiants dans .env
(DB_NAME, DB_ROOT_PASSWORD). Il maintient une table schema_migrations
(une ligne par fichier applique) : relancer ne rejoue que les nouvelles
migrations. La cible make migrate est destinee a appeler ce script.
Conventions
- Une migration = un fichier
NNNN_description.sql. Un fichier deja applique en commun n'est plus edite : on ajoute une nouvelle migration pour corriger. - Pas de
CREATE DATABASE/USEdans les fichiers : la base cible est choisie par le runner. - Le schema suit le MLD v0.2 a la lettre : montants en centimes (INT UNSIGNED),
vat_rateen pour-mille,service_dayNON materialise (calcule applicatif, decision D6), stock signe (survente), journaux append-only (stock_movement,audit_log). - Verification : le DDL a ete applique sur une instance MariaDB 11.4 reelle (21 tables, 28 FK, 22 CHECK) sans erreur avant integration.