Skip to content

feat(ra-console): frontend, socle (étape 6a) - #70

Closed
PhilippeVienne wants to merge 5 commits into
feat/ra-console-quorumfrom
feat/ra-console-frontend
Closed

feat(ra-console): frontend, socle (étape 6a)#70
PhilippeVienne wants to merge 5 commits into
feat/ra-console-quorumfrom
feat/ra-console-frontend

Conversation

@PhilippeVienne

@PhilippeVienne PhilippeVienne commented Sep 27, 2026

Copy link
Copy Markdown
Contributor

Objet

docs/WEBUI.md §15 étape 6 (frontend), tranche 6a (socle), selon docs/UI-UX.md. Choix de l'utilisateur : TypeScript + esbuild, Playwright en CI. Empilée sur #67 (feat/ra-console-quorum, tête 4525c07), comme #68 (déploiement) et #69 (registre), qui lui sont parallèles.

Ce qui est servi

  • Assets embarqués dans le binaire (include_bytes!, bin/ra-console/src/web.rs) depuis bin/ra-console/web/dist/, versionné : compiler ra-console n'exige pas Node, et l'image n'embarque ni Node ni node_modules. La CI vérifie que dist/ correspond aux sources (build reproductible, vérifié).
  • En-têtes de sécurité sur toutes les réponses, API comprise (UI-UX §6.3) : la CSP d'UI-UX à l'identique (aucun unsafe-*, rien hors origine, frame-ancestors 'none'), X-Frame-Options: DENY, nosniff, Referrer-Policy: no-referrer, COOP, Permissions-Policy, Cache-Control: no-store. http::app compose l'API, le frontend et ces en-têtes ; main et le harnais e2e l'utilisent.
  • Écrans : bannière d'environnement sur tous les écrans (OPENEIDAS_RA_ENVIRONMENT, production/staging/demo ; « ENVIRONNEMENT NON DÉCLARÉ » à défaut, via GET /api/v1/console sans session) ; connexion par nom et clé FIDO2 ; poste de travail (barre de sécurité avec identité et rôle relus sur le serveur, compteurs des files) ; déconnexion ; verrouillage après 15 min d'inactivité (avertissement à 14), session révoquée côté serveur. Aucun innerHTML : tout contenu de l'API est inséré comme texte.
  • Styles tirés des design tokens d'UI-UX §4 (thème sombre, rôles, focus). Les maquettes de docs/mockups/ (antigravity) ne sont ni modifiées ni copiées : seules leurs valeurs de tokens sont reprises.

Tests

  • bin/ra-console/tests/web.rs (cargo, sans navigateur) : en-têtes sur toutes les réponses, types et contenu des assets, environnement annoncé.
  • Playwright (bin/ra-console/web/e2e/) contre une console réelle (examples/e2e_console.rs : http::app sur PostgreSQL). L'attestation de l'authentificateur virtuel serait refusée par la liste blanche : l'opérateur est donc enregistré avec le SoftToken des tests Rust, et sa clé est confiée à l'authentificateur WebAuthn virtuel de Chromium (CDP WebAuthn.addCredential). Parcours : en-têtes et absence de script/style en ligne ; connexion FIDO2 → poste → déconnexion (session réellement révoquée, aucune erreur ni violation de CSP dans la page) ; verrouillage à 15 min (horloge simulée).
  • Mutation : sans la couche d'en-têtes, every_response_carries_the_security_headers échoue (et le test Playwright des en-têtes aussi).
  • Job CI frontend : npm ci, typage strict (navigateur et Node séparés), dist/ conforme, Chromium de Playwright, parcours e2e ; rapport en artefact en cas d'échec.

Limites et suites

Vérifications

  • npm run typecheck, npm run build (reproductible), Playwright 3/3 en local sur trois passes consécutives (Chrome installé, PW_CHANNEL=chrome).
  • cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings (1.97 et 1.98.1), cargo test --workspace avec PostgreSQL, cargo audit --ignore RUSTSEC-2023-0071, cargo deny check licenses : verts.
  • À confirmer par la CI : le job frontend (installation de Chromium par Playwright sur le runner).

Revue humaine obligatoire

Voir PROVENANCE.md. Chaque case est cochée par le
contributeur humain qui valide la PR, après l'avoir fait lui-même.

  • Revue d'architecture validée par l'humain
  • Code relu et tests unitaires/intégration vérifiés localement
  • Absence de dépendances tierces incompatibles avec la double licence EUPL-1.2 / AGPL-3.0 (make licenses)
  • Validation de l'apport intellectuel et de la paternité humaine sur la modification

Assistance par IA

  • Cette PR a été produite avec l'assistance de Claude Code : les commits concernés portent la remorque Co-authored-by: Claude <noreply@anthropic.com>, auteur et committer restent humains, et scripts/provenance.py archive a été lancé
  • Cette PR a été écrite sans assistance par IA

PhilippeVienne and others added 5 commits September 27, 2026 10:02
@PhilippeVienne @claude
feat(ra-console): préparation des actions signées approve/reject (éta…
37958f4 
…pe 3a)

docs/WEBUI.md §15 étape 3, schéma de signature §4 étapes 1 à 3 :
`POST /api/v1/webauthn/challenge` relaie à ca-server
(`/internal/v1/challenge`) l'action demandée par l'opérateur connecté ;
ca-server la fige et rend le corps qu'il exécutera, son empreinte et les
options WebAuthn.

- Le challenge vise l'opérateur de la session : `operator_hint` vient de
  la session (Authenticated gagne `operator_id`), jamais du navigateur.
  L'action est relue dans l'énumération fermée d'oe_actions puis
  resérialisée : un champ en trop ne franchit pas la console.
- Seuls approve_request et reject_request sont préparés à ce stade (403
  action_not_available sinon, sans solliciter ca-server). Le rôle et
  l'état de la demande restent jugés par ca-server.
- Journal de la console : ra.action_challenge (AppState gagne `journal`).
- action_challenge.rs, contre le vrai service d'actions de ca-server et
  PostgreSQL ; trois mutations tuées (indice venu du navigateur, filtre
  de l'étape, session non exigée).
- docs/RA-CONSOLE.md mis à jour.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): exécution des décisions signées approve/reject (éta…
457dc7e 
…pe 3b)

docs/WEBUI.md §15 étape 3, §4 étapes 5 à 7 : `POST
/api/v1/requests/{id}/approve|reject` relaie à ca-server
(`/internal/v1/actions`) l'identifiant du challenge et l'assertion brute,
jamais de corps : ca-server exécute celui qu'il a figé.

- Lien assertion ↔ demande contrôlé par ca-server (décision de
  l'utilisateur) : la console joint `expect` (action et demande du
  chemin) ; oe_actions::Service::execute_expecting le compare au corps
  figé avant de retirer l'état de la cérémonie, et refuse (409
  action_mismatch) s'il diffère. Une signature obtenue pour une demande
  ne décide jamais d'une autre, ni l'inverse de ce qui a été signé, et
  l'assertion reste utilisable sur la bonne route. `expect` ne peut que
  restreindre ; `execute` sans attente est inchangé.
- Réponse de la forme du §5 : `decided_by` est l'opérateur dont la clé a
  signé, lu dans le registre de ca-server.
- Journal de la console : ra.action_relayed.
- Tests de bout en bout (approbation, rejet, rejeu, mauvaise cible,
  corps non relayés) et unitaire d'Expect ; trois mutations tuées
  (contrôle retiré, contrôle après consommation, expect non envoyé).

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): révocation d'un certificat, première signature (éta…
aac4dbc 
…pe 4a)

docs/WEBUI.md §15 étape 4, §8 : la console prépare `revoke_certificate`
et relaie la signature par `POST /api/v1/certificates/{serial}/revoke`.
La politique de ca-server exige deux ca_operateur distincts : la
première signature est enregistrée, rien n'est révoqué
(AWAITING_QUORUM, 1/2). La co-signature est l'étape 4b.

- oe_actions::Expect gagne `serial` : ca-server compare le certificat de
  la route au corps figé avant toute consommation, comme pour une
  décision ; une cible sans rapport avec le type d'action est refusée.
- ra-console : relay_assertion factorise le relais d'une assertion
  (décisions et révocation) ; numéro de série exigé sous forme
  canonique (hexadécimal minuscule, 20 octets au plus) avant relais.
- Tests : harnais doté d'une vraie CA sur PostgreSQL et du révocateur de
  ca-server ; première signature sans révocation, mauvaise cible,
  forme non canonique, refus pour un ra_operateur. Deux mutations tuées.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): double contrôle, co-signature et salle d'attente (é…
4525c07 
…tape 4b)

docs/WEBUI.md §8, §15 étape 4 : deux ca_operateur distincts révoquent
ensemble depuis la console.

- Co-signature : `POST /api/v1/webauthn/challenge` accepte
  `{"action_id"}` (action existante, non exécutée, proposée à ce stade),
  puis `POST /api/v1/quorum/{action_id}/sign`. oe_actions::Expect gagne
  `action_id`, comparé avant toute consommation : une co-signature ne
  compte que pour l'action pour laquelle son challenge a été émis.
- Salle d'attente : `GET /api/v1/quorum?state=PENDING` lit `actions` et
  `decision_evidence` de ca-server en lecture seule (décision de
  l'utilisateur) : corps figé, empreinte, signatures, signataires. Le
  rôle de la console gagne SELECT sur `actions` (aucun secret n'y
  figure) ; le test de schéma est mis à jour.
- Écart assumé avec le §8, en plus sûr : pas de tables de collecte, la
  console ne conserve jamais d'assertion (ca-server enregistre chaque
  signature au fil de l'eau). WEBUI.md §8 dit ce qui est construit.
- Tests : révocation à deux de bout en bout, seconde signature du même
  opérateur refusée, exécution unique, co-signature présentée pour une
  autre action sur le même certificat refusée. Deux mutations tuées.
- Mise à jour d'un déploiement : rejouer ra_console_grants.sql.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne @claude
feat(ra-console): frontend, socle (étape 6a)
6e3e1c2 
docs/WEBUI.md §15 étape 6, docs/UI-UX.md : la console sert son interface,
en TypeScript compilé par esbuild (choix de l'utilisateur), sans
framework ni dépendance d'exécution.

- Assets embarqués dans le binaire (include_bytes!, src/web.rs) depuis
  web/dist, versionné : compiler ra-console n'exige pas Node.
- En-têtes de sécurité sur toutes les réponses, API comprise (UI-UX
  §6.3) : CSP stricte sans unsafe-inline ni CDN, frame-ancestors 'none',
  X-Frame-Options DENY, nosniff, Referrer-Policy, Cache-Control no-store.
  `http::app` compose l'API, le frontend et ces en-têtes.
- Bannière d'environnement (OPENEIDAS_RA_ENVIRONMENT, « non déclaré » à
  défaut), connexion par nom et clé FIDO2, poste de travail (identité et
  rôle relus sur le serveur, compteurs des files), déconnexion,
  verrouillage après 15 min d'inactivité (avertissement à 14). Aucun
  innerHTML : le contenu de l'API est inséré en texte.
- Tests : tests/web.rs (en-têtes et assets, sans navigateur) ; Playwright
  contre une console réelle (examples/e2e_console.rs, PostgreSQL), clé du
  SoftToken confiée à l'authentificateur WebAuthn virtuel de Chromium.
- CI : job frontend (typage strict, dist/ conforme aux sources, parcours
  de bout en bout). Dépendances npm de développement seulement (esbuild
  MIT, TypeScript et Playwright Apache-2.0), jamais dans l'image.

Co-authored-by: Claude <noreply@anthropic.com>
@PhilippeVienne PhilippeVienne mentioned this pull request Sep 27, 2026
Closed
6 tasks
@PhilippeVienne
PhilippeVienne force-pushed the feat/ra-console-quorum branch 5 times, most recently from 9e06cda to 84a7de1 Compare September 30, 2026 15:12
@PhilippeVienne
PhilippeVienne deleted the branch feat/ra-console-quorum September 30, 2026 15:52
@PhilippeVienne PhilippeVienne mentioned this pull request Sep 30, 2026
Merged
6 tasks
@PhilippeVienne

PhilippeVienne commented Sep 30, 2026

Copy link
Copy Markdown
Contributor Author

Remplacée par #87 (base dev) : fermée par GitHub à la suppression de sa branche de base après la fusion de #83.

@PhilippeVienne PhilippeVienne mentioned this pull request Sep 30, 2026
Merged
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@PhilippeVienne