4nk/anchorage_layer_simple
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
anchorage_layer_simple/features/website-skeleton-partie-connectee-pairing-relay.md
ncantu f9fe0e3419 Website-skeleton partie connectée, contrat en dur, navigate-login; UserWallet pairing-relay-status, redirect; website-data, proxy data, cryptographie, fixKnowledge 
**Motivations:**
- Partie connectée du skeleton accessible seulement si pairing satisfait + relais OK, avec page type skeleton (avatar, notifications).
- Éviter « Aucun service disponible » : contrat présent en dur dans la page, transmis à l’iframe ; navigation évidente ou automatique vers login.
- Sécuriser postMessage (origine UserWallet uniquement) ; déployer data sur le proxy et certificat data.certificator.4nkweb.com.
- Vulgariser cryptographie (ECDH, AES-GCM, Schnorr, workflow, collecte signatures) ; documenter correctifs et architecture.

**Root causes:**
- Section connectée affichée sans vérifier pairing/relay ; possibilité de forger pairing-relay-status depuis la console.
- Iframe masquée ou /login chargé avant réception du contrat → graphe vide, redirection vers /services.
- Pas de contrôle d’origine sur les messages reçus ; pas de projet website-data ni config Nginx/certificat pour data.

**Correctifs:**
- Vérification msg.origin === USERWALLET_ORIGIN dans handleMessage (skeleton).
- Si session mais pas pairingRelayStatus : afficher iframe pour réception du statut, message « Vérification du statut… ».
- Contrat envoyé dès load iframe (init iframe.src = USERWALLET_ORIGIN) ; au clic « Se connecter », envoi contract + navigate-login (service, membre).
- UserWallet : écoute navigate-login → navigation /login?service=&membre= ; LoginScreen avec service+membre en URL ne redirige plus vers /services, dispatch E_SELECT_SERVICE / E_SELECT_MEMBER.

**Evolutions:**
- Message pairing-relay-status (iframe → parent) ; canShowConnectedSection exige login + pairing OK + relay OK ; page connectée avec header avatar + icône notifications.
- Skeleton : getLoginContext, sendNavigateLoginToIframe, onIframeLoad, loginRequested/iframeLoaded ; contrat envoyé avec serviceUuid, membreUuid.
- UserWallet : PairingRelayStatusMessage, envoi depuis HomeScreen/LoginScreen ; type navigate-login, handleNavigateLogin dans useChannel.
- Page cryptographie.html (workflow, algorithmes, collecte signatures) ; liens nav, build.
- website-data (Vite, channel, config), start/service/install ; configure-nginx-proxy + Certbot pour data.certificator.4nkweb.com.
- fixKnowledge (postmessage-origin, section-connectee-non-affichee) ; features (partie-connectee-pairing-relay, userwallet-iframe-key-isolation).

**Pages affectées:**
- website-skeleton (index, main, config, serviceContract, cryptographie, technique, membre, contrat, vite.config, README).
- userwallet (HomeScreen, LoginScreen, useChannel, iframeChannel, relay, crypto, iframe, Pairing*, RelaySettings, WordInputGrid, syncUpdateGraph, specs/synthese).
- website-data (nouveau), configure-nginx-proxy, docs DOMAINS_AND_PORTS README, features, fixKnowledge, userwallet features/docs.
2026-01-29 00:55:58 +01:00

2.4 KiB
Raw Blame History

Website-skeleton: partie connectée conditionnée au pairing et au relais

Objectif: La partie connectée du website-skeleton n’est accessible que si le statut pairing est satisfait (Requis: Oui, Satisfait: Oui) et le statut réseau relais est OK. La page connectée adopte un style skeleton avec avatar et icône notifications.

Impacts:

  • UserWallet envoie au parent (postMessage) un message pairing-relay-status avec pairingSatisfied et relayOk.
  • Website-skeleton affiche la section connectée uniquement lorsque l’utilisateur est connecté (login-proof reçu) et que le dernier pairing-relay-status reçu indique les deux conditions remplies.
  • La page connectée affiche un en-tête type skeleton avec photo d’avatar (placeholder) et bouton icône notifications.

Modifications:

  • userwallet
    • src/utils/iframeChannel.ts: nouveau type de message pairing-relay-status et interface PairingRelayStatusMessage.
    • src/components/HomeScreen.tsx: en iframe, envoi de pairing-relay-status lorsque pairing et relay changent.
    • src/components/LoginScreen.tsx: en iframe, envoi de pairing-relay-status (pairing satisfait, relay OK) pour que le parent reçoive l’état avant ou avec le login-proof.
  • website-skeleton
    • src/main.ts: réception de pairing-relay-status, stockage du dernier état; canShowConnectedSection() exige login + pairing satisfait + relay OK; updateUI() utilise cette condition pour afficher la section connectée. Vérification de msg.origin === USERWALLET_ORIGIN dans handleMessage pour n’accepter que les messages provenant de l’iframe UserWallet (évite qu’un script ou la console forge un message et force l’accès à la partie connectée).
    • index.html: section connectée refaite avec en-tête (avatar placeholder, icône notifications), liens et bouton déconnexion inchangés.

Modalités de déploiement: Déploiement classique du website-skeleton et du userwallet (build puis déploiement des artefacts).

Modalités d’analyse: Vérifier en conditions réelles : 1) sans pairing/relay OK, après login-proof la section connectée ne s’affiche pas ; 2) avec pairing satisfait et relay OK, après login-proof la section connectée s’affiche avec avatar et icône notifications ; 3) si le statut pairing ou relay repasse à non satisfait après connexion, la section connectée disparaît.