Skip to content

feat(ra-console): lecture seule de la file d'enrôlement (2a) - #40

Merged
PhilippeVienne merged 1 commit into
devfrom
feat/ra-console-requests
Sep 25, 2026
Merged

PhilippeVienne merged 1 commit into
devfrom
feat/ra-console-requests

Conversation

@PhilippeVienne

Copy link
Copy Markdown
Contributor

Contexte

Étape 2 du plan WEBUI §15 (lecture seule), premier morceau convenu (2a). Base dev : la pile 1c est mergée.

Contenu

  • GET /api/v1/requests?state=PENDING : lit directement enrollment_requests, table déjà en lecture seule pour ra-console (ra_console_grants.sql). Aucun aller-retour vers ca-server.
  • Écrit en SQL direct plutôt que via oe-castore : Postgres::open exécute les migrations, hors de portée du rôle PostgreSQL restreint de la console (pas de droits DDL). Aucune nouvelle dépendance normale.
  • Un extracteur crate::http::authenticate factorisé, réutilisé par /api/v1/me et cette nouvelle route, posé pour les prochaines routes authentifiées.
  • Le rôle minimal documenté (auditeur) n'est pas vérifié : docs/WEBUI.md §3 est explicite — les contrôles de rôle de ra-console ne sont qu'un affichage, la vraie barrière reste côté ca-server pour l'écriture.

Ce qui reste ouvert (2b, reportée, décidé avec vous)

GET /api/v1/audit/search doit relire deux journaux chaînés (§7) : celui de ca-server (fichier local à son pod) et celui de ra-console (à créer). Rien dans WEBUI.md ne dit comment ra-console accède au fichier de ca-server (volume partagé ? route interne dédiée ?). À trancher avant d'écrire, probablement au moment du déploiement Helm.

Vérifications

  • cargo fmt --check
  • cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1 — un clippy::result_large_err propre à 1.98 sur l'extracteur d'authentification, autorisé explicitement : la grande valeur Err est la réponse HTTP à renvoyer telle quelle)
  • cargo test --workspace (avec OE_CASTORE_TEST_DSN) : vert, y compris le nouveau test de bout en bout
  • cargo audit --ignore RUSTSEC-2023-0071 : rien à signaler
  • Contrôle par mutation : l'authentification et la validation de l'état demandé échouent chacune pour la bonne raison quand on retire le contrôle correspondant

GET /api/v1/requests?state=PENDING (docs/WEBUI.md §5, §15 étape 2a) : lit
directement enrollment_requests, table dont ra-console n'a que le SELECT
(ra_console_grants.sql). Aucun aller-retour vers ca-server, aucune nouvelle
dépendance : la lecture est écrite en SQL direct dans ra-console plutôt que
via oe-castore (dont Postgres::open exécute les migrations, hors de portée
du rôle PostgreSQL de la console).

Un extracteur de session authentifiée réutilisable (crate::http::authenticate)
remplace le code dupliqué de /api/v1/me, posé pour toutes les routes
authentifiées à venir. Le rôle minimal documenté (auditeur) n'est pas vérifié :
les contrôles de rôle de ra-console ne sont qu'un affichage (§3), la vraie
barrière reste côté ca-server pour l'écriture — décider (approve/reject,
étape 3) restera relayé et vérifié là-bas.

GET /api/v1/audit/search (2b) reste ouverte : question non résolue dans
WEBUI.md sur l'accès de ra-console au journal chaîné local de ca-server.

Vérifications : cargo fmt --check, cargo clippy --workspace --all-targets
(1.97 et 1.98.1 — un clippy::result_large_err propre à 1.98 sur l'extracteur
d'authentification, autorisé explicitement : la grande valeur Err est la
réponse HTTP à renvoyer telle quelle), cargo test --workspace (avec
OE_CASTORE_TEST_DSN), cargo audit. Contrôle par mutation : l'authentification
et la validation de l'état demandé échouent chacune pour la bonne raison
quand on retire le contrôle correspondant.
@PhilippeVienne
PhilippeVienne merged commit 357608e into dev Sep 25, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant