4nk/anchorage_layer_simple
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
anchorage_layer_simple/features/website-data-architecture.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.0 KiB
Raw Blame History

website-data — architecture site <-> data <-> userwallet

Objectif

Projet iframe data (data.certificator.4nkweb.com) dédié aux données non clés, qui communique avec le site et avec UserWallet (clés, relais). Flux :

site <-> data (+notifications) <-> userwallet (sur les relais)

Impacts

  • Nouveau projet website-data/ (Vite, TypeScript), servi sur data.certificator.4nkweb.com (port 3025).
  • Le site parent intègre une seule iframe Data. Data embarque UserWallet en iframe enfant.
  • Contrat, auth, login-proof, etc. transitent par Data entre site et UserWallet.
  • Les clés et la crypto restent dans UserWallet ; Data ne fait aucune opération de signature/chiffrement.

Modifications

  • website-data : package.json, vite.config.ts, index.html, src/config.ts, src/channel.ts, src/main.ts.
  • Messages postMessage : Site ↔ Data (contract, auth-request, data-request, data-response, notification, pong, error, login-proof, auth-response, service-status). Data ↔ UserWallet : mêmes types applicables, relayés.
  • Notifications : Data → Site (notification avec kind / detail). Actuellement pour userwallet:login-proof, userwallet:auth-response, userwallet:error. Placeholder pour notifications relay (data non clés).

Modalités de déploiement

  • Build website-data (npm run build), servir dist/ sur le port 3025.
  • Configurer Nginx (ou équivalent) pour data.certificator.4nkweb.com → backend 3025, certificat Let’s Encrypt.
  • S’aligner sur la procédure utilisée pour website-skeleton / userwallet (cf. docs infrastructure 4NK).

Modalités d’analyse

  • Ouvrir le site parent avec iframe Data (src = data.certificator.4nkweb.com ou localhost:3025 en dev).
  • Envoyer contract, auth-request au Data iframe ; vérifier relay vers UserWallet et réponses (login-proof, etc.) remontées au site.
  • Vérifier les notification reçues par le site (kind userwallet:*).

Pages affectées

  • website-data/ (nouveau)
  • features/website-data-architecture.md (ce document)