8208809f03
**Motivations:** - Parcours login contrat: sélection service → membre → build path → proof, vérification côté parent (service-login-verify) - Scripts data: initialisation SQLite (utxos, anchors, fees), migration depuis fichiers, sync UTXOs - Website-skeleton: intégration contrat, extraction validateurs login, vérification preuve **Root causes:** - N/A (évolutions) **Correctifs:** - N/A **Evolutions:** - UserWallet: MemberSelectionScreen, LoginScreen machine à états (S_LOGIN_SELECT_SERVICE → S_LOGIN_SELECT_MEMBER → build path), service/membre via query params, useChannel/iframeChannel - Website-skeleton: contract.ts (extractLoginValidators, isValidContract, isValidAction), main.ts validateurs depuis contrat, config étendu - Data: init-db.js (tables utxos/anchors/fees), migrate-from-files.js **Pages affectées:** - data/init-db.js, data/migrate-from-files.js, data/sync-utxos.log - userwallet: App, LoginCollectShare, LoginScreen, MemberSelectionScreen, ServiceListScreen, useChannel, iframeChannel - website-skeleton: README, config, contract, main
87 lines
3.9 KiB
Markdown
87 lines
3.9 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é : … ».
|
||
|
||
## 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)
|