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.
40 lines
2.0 KiB
Markdown
40 lines
2.0 KiB
Markdown
# 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)
|