ncantu f27345e0ba RESTE_A_FAIRE, relay validation, verify proof structure, UserWallet diagnostic/sync
**Motivations:**
- Documenter le reste à faire (userwallet, service-login-verify, api-relay, website-skeleton)
- Renforcer la validation côté api-relay et service-login-verify
- Ajouter écrans diagnostic et sync service, service notifications relais, contrat par défaut

**Root causes:**
- N/A (évolutions + correctifs ciblés)

**Correctifs:**
- api-relay: GET /:hash (keys, messages, signatures) rejette hash vide → 400
- service-login-verify: validation structure preuve (challenge.hash, nonce, timestamp, signatures), reason invalid_proof_structure

**Evolutions:**
- RESTE_A_FAIRE.md: vue d’ensemble et tâches par projet
- UserWallet: DiagnosticScreen, ServiceSyncScreen, relayNotificationService (hash events, fetch, decrypt, graph), defaultContract, loginStateMachine, useChannel, loginPublish, LoginScreen, LoginCollectShare
- website-skeleton: README étendu

**Pages affectées:**
- RESTE_A_FAIRE.md
- api-relay: keys, messages, signatures
- service-login-verify: types, verifyLoginProof
- userwallet: App, DiagnosticScreen, LoginCollectShare, LoginScreen, ServiceSyncScreen, useChannel, loginStateMachine, relayNotificationService, defaultContract, loginPublish
- website-skeleton: README
2026-01-28 01:37:16 +01:00

183 lines
6.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# website-skeleton
Squelette d'un site qui intègre UserWallet en iframe : écoute des messages `postMessage` (auth-request, login-proof, error, contract), vérification des preuves de login via `service-login-verify`, et affichage du statut (accepté / refusé).
## Prérequis
- **service-login-verify** : `npm run build` dans `../service-login-verify` avant d'installer ou builder le skeleton.
- **UserWallet** : à servir sur l'URL configurée (voir cidessous) pour que l'iframe fonctionne.
## Installation
```bash
cd website-skeleton
npm install
npm run build
```
## Développement
```bash
npm run dev
```
Ouvre par défaut sur `http://localhost:3024`. L'iframe pointe vers UserWallet (`USERWALLET_ORIGIN`).
## Configuration
- **Origine UserWallet** : `src/config.ts` définit `USERWALLET_ORIGIN`. En dev, défaut `http://localhost:3018` (si UserWallet tourne en dev sur ce port). En prod, défaut `https://userwallet.certificator.4nkweb.com`. Pour override : variable d'environnement `VITE_USERWALLET_ORIGIN` (ex. `VITE_USERWALLET_ORIGIN=http://localhost:3018 npm run dev`).
- **Validateurs** : `DEFAULT_VALIDATEURS` dans `src/config.ts` est un placeholder. Le skeleton charge dynamiquement les validateurs depuis les contrats reçus via channel messages (type `contract`). Si aucun contrat n'est reçu, les validateurs par défaut sont utilisés.
### Chargement dynamique des contrats
Le skeleton écoute les messages `postMessage` de type `contract` pour recevoir le contrat et mettre à jour les validateurs dynamiquement :
```javascript
// Exemple d'envoi de contrat depuis le parent
window.postMessage({
type: 'contract',
payload: {
contrat: {
uuid: '...',
validateurs: { membres_du_role: [...] },
datajson: { types_names_chiffres: 'contrat' }
},
contrats_fils: [...], // Optionnel
actions: [...] // Optionnel, pour extraire l'action login
}
}, '*');
```
Le skeleton :
1. Reçoit le message `contract`
2. Extrait les validateurs de l'action login (recherche dans `actions` pour un type contenant "login")
3. Met à jour les `allowedPubkeys` utilisés pour la vérification
4. Affiche un statut de confirmation
Si aucun contrat n'est reçu, les `DEFAULT_VALIDATEURS` sont utilisés comme fallback.
## Utilisation
1. Lancer UserWallet (dev ou déployé) sur l'URL configurée.
2. Lancer le skeleton (`npm run dev` ou servir `dist/`).
3. Ouvrir la page du skeleton : l'iframe affiche UserWallet.
4. **Envoyer contrat (optionnel)** : envoyer un message `contract` avec le contrat et ses actions pour mettre à jour les validateurs.
5. **Demander auth** : bouton « Demander auth (auth-request) » → envoi de `auth-request` à l'iframe.
6. **Login** : depuis l'iframe, effectuer le flux de login ; à la fin, UserWallet envoie `login-proof` au parent. Le skeleton vérifie la preuve (`verifyLoginProof`) et affiche « Login accepté » ou « Login refusé : … ».
## Exemple d'intégration
### Envoi de contrat depuis le parent
```javascript
// Depuis la page parente qui héberge l'iframe
const iframe = document.getElementById('userwallet');
const userwalletOrigin = 'https://userwallet.example.com';
// Envoyer le contrat avec l'action login
iframe.contentWindow.postMessage({
type: 'contract',
payload: {
contrat: {
uuid: 'contrat-uuid-123',
validateurs: {
membres_du_role: [
{
membre_uuid: 'membre-uuid-456',
signatures_obligatoires: [
{
membre_uuid: 'membre-uuid-456',
cle_publique: '02abc123...', // Clé publique secp256k1
cardinalite_minimale: 1
}
]
}
]
},
datajson: {
types_names_chiffres: 'contrat'
}
},
contrats_fils: [], // Optionnel
actions: [
{
uuid: 'action-login-uuid',
types: {
types_names_chiffres: 'action-login',
types_uuid: ['action-uuid']
},
validateurs_action: {
membres_du_role: [
{
membre_uuid: 'membre-uuid-456',
signatures_obligatoires: [
{
membre_uuid: 'membre-uuid-456',
cle_publique: '02abc123...',
cardinalite_minimale: 1
}
]
}
]
}
}
]
}
}, userwalletOrigin);
```
### Réception et vérification de login-proof
Le skeleton écoute automatiquement les messages `login-proof` et vérifie la preuve :
```javascript
// Le skeleton fait automatiquement :
window.addEventListener('message', (event) => {
if (event.data?.type === 'login-proof') {
const result = verifyLoginProof(event.data.payload, {
allowedPubkeys, // Construit depuis les validateurs
nonceCache, // Cache anti-rejeu
timestampWindowMs: 300000 // 5 minutes
});
if (result.accept) {
// Ouvrir la session utilisateur
console.log('Login accepté');
} else {
// Refuser le login
console.error('Login refusé:', result.reason);
}
}
});
```
### Gestion des erreurs
Les raisons de refus possibles :
- `invalid_proof_structure` : Structure de la preuve invalide
- `timestamp_out_of_window` : Timestamp hors fenêtre (défaut ±5 min)
- `nonce_reused` : Nonce déjà utilisé (anti-rejeu)
- `validators_not_verifiable` : Aucune clé publique dans les validateurs
- `no_validator_signature` : Aucune signature valide de validateurs
- `signature_cle_publique_not_authorized` : Signature avec clé non autorisée
## Structure
- `index.html` : page avec iframe, zone de statut, bouton auth.
- `src/main.ts` : chargement de l'iframe, écoute `message`, envoi `auth-request`, appel à `verifyLoginProof`, mise à jour du statut, gestion des messages `contract`.
- `src/config.ts` : `USERWALLET_ORIGIN`, `DEFAULT_VALIDATEURS`, types `Contrat` et `Action`.
- `src/contract.ts` : extraction des validateurs depuis les contrats (`extractLoginValidators`), validation de structure (`isValidContract`, `isValidAction`).
## Déploiement
- **Production** : `https://skeleton.certificator.4nkweb.com` (proxy → 192.168.1.105:3024).
- **Installation** : `./install-website-skeleton.sh` sur le backend, puis `./update-proxy-nginx.sh` pour proxy + certificat. Voir `docs/WEBSITE_SKELETON.md`.
## Références
- `docs/WEBSITE_SKELETON.md` (documentation détaillée)
- `features/service-login-verify.md`
- `features/userwallet-contrat-login-reste-a-faire.md` (§ 3.7)
- `userwallet/` (iframe)
- `service-login-verify/` (vérification)