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.
22 lines
2.4 KiB
Markdown
22 lines
2.4 KiB
Markdown
# 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.
|