f27345e0ba
**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
203 lines
7.1 KiB
Markdown
203 lines
7.1 KiB
Markdown
# Reste à faire - Projets UserWallet
|
|
|
|
**Author:** Équipe 4NK
|
|
**Date:** 2026-01-28
|
|
|
|
## Vue d'ensemble
|
|
|
|
Ce document liste les éléments restants à implémenter ou à valider pour les projets :
|
|
- `userwallet`
|
|
- `service-login-verify`
|
|
- `api-relay`
|
|
- `website-skeleton`
|
|
|
|
---
|
|
|
|
## 1. userwallet
|
|
|
|
### 1.1 Écrans login (Priorité : Haute - À valider)
|
|
|
|
**Statut :** À valider avant implémentation
|
|
**Référence :** `features/userwallet-ecrans-login-a-valider.md`
|
|
|
|
Les écrans suivants sont déjà en place mais nécessitent validation et éventuelles améliorations :
|
|
- Sélection service / sélection membre
|
|
- Construction du chemin login
|
|
- Message de login à valider
|
|
- Collecte signatures mFA
|
|
- Publication
|
|
- Vérification locale + résultat
|
|
|
|
**Action requise :** Validation des écrans existants et ajustements selon les retours de tests.
|
|
|
|
### 1.2 Notifications relais (Priorité : Haute)
|
|
|
|
**Statut :** Partiellement implémenté
|
|
**Référence :** `features/userwallet-contrat-login-reste-a-faire.md` (§ 3.2)
|
|
|
|
**Fait :**
|
|
- Progression collecte signatures (X/Y) implémentée via `onProgress` dans `runCollectLoop`
|
|
- Affichage dans `LoginCollectShare`
|
|
|
|
**Reste à faire :**
|
|
- Réagir à d'autres événements relais si extension (ex. push)
|
|
- Hash à fetch pour signatures, contrats, membres, pairs, actions, champs
|
|
- Une fois le hash connu : récupération sur le relai des signatures, contrats, membres, pairs, actions, champs
|
|
- Les notifications doivent piloter : quel hash fetch, puis fetch signatures/clés et mise à jour du graphe
|
|
|
|
### 1.3 Merkle trees (Priorité : Basse - Optionnel)
|
|
|
|
**Statut :** Non implémenté (optionnel)
|
|
**Référence :** `features/userwallet-contrat-login-reste-a-faire.md` (§ 3.6)
|
|
|
|
**Description :** Checkpointing / accélération de scan pour optimiser la synchronisation à grande échelle.
|
|
|
|
**Impact :** Amélioration de performance pour les volumes importants de données.
|
|
|
|
### 1.4 Écran "synchronisation continue par service" (Priorité : Moyenne)
|
|
|
|
**Statut :** Non implémenté
|
|
**Référence :** `userwallet/docs/specs.md` (§ Écran "synchronisation continue par service")
|
|
|
|
**Fonctionnalités attendues :**
|
|
- Liste services + toggle sync automatique
|
|
- Fréquence (min/heure/jour)
|
|
- Fenêtre de scan
|
|
- Accélérateurs : Bloom filter (taille, faux positifs estimés), Merkle (segments/périodes)
|
|
- Bouton "lancer maintenant"
|
|
|
|
**Traitements locaux :**
|
|
- GET messages depuis dernier checkpoint
|
|
- Dédup hash
|
|
- Fetch signatures et clés si nécessaire
|
|
- Validation graphe et droits
|
|
|
|
**États / erreurs :**
|
|
- Volume trop important → recommander Bloom/Merkle
|
|
- Relais instables → backoff
|
|
|
|
### 1.5 Écran "paramètres crypto (avancé)" (Priorité : Basse)
|
|
|
|
**Statut :** Non implémenté
|
|
**Référence :** `userwallet/docs/specs.md` (§ Écran "paramètres crypto (avancé)")
|
|
|
|
**Fonctionnalités attendues :**
|
|
- Algorithme hash (ex : sha256)
|
|
- Canonisation JSON (mode strict)
|
|
- Paramètres ECDH (secp256k1)
|
|
- Paramètres KDF/symétrique (si exposés)
|
|
- Politique anti-rejeu : TTL nonce, fenêtre timestamp
|
|
|
|
**États / erreurs :**
|
|
- Incompatibilité avec services existants
|
|
- Paramètres non supportés par version logicielle
|
|
|
|
### 1.6 Validation stricte CNIL (Priorité : Moyenne)
|
|
|
|
**Statut :** Non implémentée
|
|
**Référence :** `features/userwallet-champs-obligatoires-cnil.md`
|
|
|
|
**Description :** Validation stricte CNIL (présence des champs lorsque requis) non implémentée ; à prévoir selon politique métier.
|
|
|
|
**Action requise :** Définir la politique métier et implémenter la validation.
|
|
|
|
### 1.7 Corrections ESLint (Priorité : Moyenne)
|
|
|
|
**Statut :** Environ 95 erreurs restantes
|
|
**Référence :** `features/userwallet-eslint-fix.md`
|
|
|
|
**Types d'erreurs :**
|
|
- `max-lines` : fichiers trop longs
|
|
- `max-lines-per-function` : fonctions trop longues
|
|
- `complexity` : complexité cyclomatique élevée
|
|
- `max-params` : trop de paramètres
|
|
- `no-non-null-assertion` : utilisation de `!`
|
|
- Et autres violations
|
|
|
|
**Action requise :** Refactoring progressif pour corriger les violations.
|
|
|
|
---
|
|
|
|
## 2. service-login-verify
|
|
|
|
### 2.1 Persistance du NonceCache (Priorité : Basse - Optionnel)
|
|
|
|
**Statut :** Actuellement en mémoire uniquement
|
|
**Référence :** `features/service-login-verify.md`
|
|
|
|
**Description :** Le `NonceCache` actuel est en mémoire avec TTL configurable. Une persistance optionnelle (IndexedDB, Redis, etc.) peut être ajoutée si nécessaire.
|
|
|
|
**Note :** L'interface `NonceCacheLike` permet déjà d'implémenter une version persistante. Le cache en mémoire est suffisant pour la plupart des cas d'usage.
|
|
|
|
**Action requise :** Implémenter uniquement si besoin de persistance entre redémarrages du service.
|
|
|
|
---
|
|
|
|
## 3. api-relay
|
|
|
|
### 3.1 Évolutions futures (Priorité : Basse - Optionnel)
|
|
|
|
**Statut :** Non implémentées (évolutions futures possibles)
|
|
**Référence :** `userwallet/features/api-relay.md`
|
|
|
|
**Évolutions mentionnées :**
|
|
- **Base de données** : Remplacer le stockage en mémoire par une base de données (SQLite, PostgreSQL)
|
|
- **Authentification** : Ajouter une authentification pour les endpoints POST
|
|
- **Rate limiting** : Limiter le nombre de requêtes par IP (déjà implémenté partiellement)
|
|
- **Compression** : Compresser les messages stockés
|
|
- **Indexation avancée** : Indexer par service UUID, type UUID pour des requêtes plus rapides
|
|
- **WebSocket** : Support WebSocket pour les notifications en temps réel (optionnel, car le modèle est pull-only)
|
|
- **Métriques** : Exposer des métriques (Prometheus, etc.) - déjà implémenté partiellement
|
|
- **Logging structuré** : Utiliser un logger structuré (Winston, Pino, etc.) - déjà implémenté (Pino)
|
|
|
|
**Note :** La plupart de ces évolutions sont optionnelles et dépendent des besoins de production.
|
|
|
|
---
|
|
|
|
## 4. website-skeleton
|
|
|
|
### 4.1 Aucun élément manquant identifié
|
|
|
|
**Statut :** Complet
|
|
**Description :** Aucun élément spécifique mentionné comme manquant dans la documentation.
|
|
|
|
---
|
|
|
|
## Synthèse par priorité
|
|
|
|
### Priorité Haute
|
|
1. **userwallet** : Validation des écrans login (1.1)
|
|
2. **userwallet** : Notifications relais - événements push (1.2)
|
|
|
|
### Priorité Moyenne
|
|
3. **userwallet** : Écran "synchronisation continue par service" (1.4)
|
|
4. **userwallet** : Validation stricte CNIL (1.6)
|
|
5. **userwallet** : Corrections ESLint (1.7)
|
|
|
|
### Priorité Basse (Optionnel)
|
|
6. **userwallet** : Merkle trees (1.3)
|
|
7. **userwallet** : Écran "paramètres crypto (avancé)" (1.5)
|
|
8. **service-login-verify** : Persistance du NonceCache (2.1)
|
|
9. **api-relay** : Évolutions futures (3.1)
|
|
|
|
---
|
|
|
|
## Notes importantes
|
|
|
|
- Les éléments marqués "À valider" nécessitent une validation explicite avant implémentation.
|
|
- Les éléments optionnels peuvent être implémentés selon les besoins et contraintes.
|
|
- Les corrections ESLint doivent être faites progressivement pour ne pas bloquer le développement.
|
|
- La plupart des fonctionnalités de base sont implémentées et fonctionnelles.
|
|
|
|
---
|
|
|
|
## Références
|
|
|
|
- `features/userwallet-contrat-login-reste-a-faire.md`
|
|
- `features/userwallet-ecrans-login-a-valider.md`
|
|
- `features/userwallet-champs-obligatoires-cnil.md`
|
|
- `features/userwallet-eslint-fix.md`
|
|
- `features/service-login-verify.md`
|
|
- `userwallet/docs/specs.md`
|
|
- `userwallet/features/api-relay.md`
|