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

3.1 KiB

Raw Blame History

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 des notification (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_ORIGIN pour la cible postMessage depuis le site (dev http://localhost:3025, prod https://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:error lors 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 pour website-skeleton. Voir docs/ 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.

3.1 KiB Raw Blame History Unescape Escape