f9fe0e3419
**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.
website-data
Iframe dédiée à la data (données non clés) à data.certificator.4nkweb.com. Elle communique avec le site (parent) et avec UserWallet (clés, relais).
Architecture
site <-> data (+notifications) <-> userwallet (sur les relais)
- Site : intègre l’iframe Data, envoie
contract,auth-request,data-request, etc. - Data : iframe dédiée aux données (hors clés). Relaye contrat / auth vers UserWallet ; reçoit
login-proof,auth-response, etc. et les transmet au site. Émet desnotification(ex.userwallet:login-proof). - UserWallet : embarquée par Data, gère clés et relais (sync, signatures). Tourne sur les relais (api-relay).
Data n’héberge aucune clé ; toute la crypto reste dans UserWallet.
Prérequis
- UserWallet : servi sur l’URL configurée (voir ci‑dessous).
Installation
cd website-data
npm install
npm run build
Développement
npm run dev
Ouvre par défaut sur http://localhost:3025. En standalone, la page indique qu’il faut l’embedder dans un parent pour le flux site <-> data <-> userwallet.
Configuration
- UserWallet :
src/config.ts,USERWALLET_ORIGIN. En dev :http://localhost:3018. En prod :https://userwallet.certificator.4nkweb.com. Override :VITE_USERWALLET_ORIGIN. - Data :
VITE_DATA_ORIGINpour la cible postMessage depuis le site (devhttp://localhost:3025, prodhttps://data.certificator.4nkweb.com).
Messages postMessage
Site → Data
| Type | Rôle |
|---|---|
contract |
Contrat + contrats_fils + actions → transmis à UserWallet |
auth-request |
Demande d’auth → transmise à UserWallet |
data-request |
Requête data (réponse data-response) |
ping |
Réponse pong |
Data → Site
| Type | Rôle |
|---|---|
data-response |
Réponse à data-request |
notification |
Événements (ex. userwallet:login-proof, userwallet:auth-response, userwallet:error) |
pong |
Réponse à ping |
error |
Erreur |
login-proof, auth-response, service-status |
Relayés depuis UserWallet |
Data ↔ UserWallet
Data embarque UserWallet en iframe. Elle envoie contract, auth-request et reçoit login-proof, auth-response, error, service-status, qu’elle relaye au site.
Notifications
Data envoie des notification au site avec payload: { kind, detail }, notamment :
userwallet:login-proof,userwallet:auth-response,userwallet:errorlors des événements UserWallet.- Un flux relay (non implémenté) pourra alimenter des
notificationà partir des relais (data non clés).
Production
- Domaine :
data.certificator.4nkweb.com - Port : 3025 (configurable dans
vite.config.ts). - Déploiement : build
dist/, servir via Nginx / systemd comme pourwebsite-skeleton. Voirdocs/et infra 4NK pour proxy et certificats.
Fichiers principaux
src/config.ts: origines Data et UserWallet.src/channel.ts: types et helpers postMessage (site <-> data, data <-> userwallet).src/main.ts: init, relay site/userwallet, notifications.