**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
183 lines
6.5 KiB
Markdown
183 lines
6.5 KiB
Markdown
# 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 ci‑dessous) 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)
|