anchorage_layer_simple/features/login-bout-en-bout-reste-a-faire.md

Login fonctionnel de bout en bout PC et Mobile - Reste à faire

Author: Équipe 4NK
Date: 2026-01-28

Vue d'ensemble

Ce document liste ce qui reste à implémenter pour avoir un login fonctionnel de bout en bout sur PC et mobile pour les projets :

• website-skeleton
• userwallet
• service-login-verify
• api-relay

---

1. website-skeleton

1.1 Envoi du contrat au UserWallet (Priorité : Haute)

Statut : ✅ Implémenté
Référence : website-skeleton/src/main.ts

Fait :

• ✅ Fonction sendContractToIframe() qui envoie le contrat stocké à l'iframe
• ✅ Stockage du contrat reçu pour envoi ultérieur (storedContract, storedContratsFils, storedActions)
• ✅ Envoi automatique du contrat au chargement de l'iframe (événement load)
• ✅ Envoi du contrat lors de la réception d'un nouveau contrat via postMessage
• ✅ Réception des messages contract depuis le parent (écoute postMessage)
• ✅ Extraction des validateurs depuis les contrats reçus
• ✅ Mise à jour des clés autorisées pour la vérification

Note : L'implémentation est complète. Le contrat est envoyé automatiquement à l'iframe dès qu'il est disponible.

1.2 Gestion de session utilisateur (Priorité : Haute)

Statut : ✅ Implémenté
Référence : website-skeleton/src/main.ts, website-skeleton/index.html

Fait :

• ✅ Stockage de session dans sessionStorage après acceptation de la preuve
• ✅ Fonctions getSession(), setSession(), clearSession(), isLoggedIn()
• ✅ Masquage de l'iframe après login réussi
• ✅ Affichage d'une interface "connecté" avec informations utilisateur (clés publiques)
• ✅ Bouton de déconnexion fonctionnel
• ✅ Vérification de session au chargement de la page
• ✅ Mise à jour automatique de l'interface selon l'état de connexion
• ✅ Vérification de la preuve de login avec verifyLoginProof()
• ✅ Affichage du statut (accepté/refusé)

Note : L'implémentation est complète. La protection des routes/endpoints reste à implémenter si nécessaire selon les besoins spécifiques du service.

1.3 Interface responsive mobile (Priorité : Moyenne)

Statut : ✅ Implémenté (à tester)

Fait :

• ✅ Meta viewport configuré (width=device-width, initial-scale=1.0)
• ✅ Styles CSS responsive avec media queries (768px, 480px)
• ✅ Adaptation de l'iframe pour mobile (hauteurs différentes selon taille d'écran)
• ✅ Boutons adaptés au tactile (min-height: 44px, width: 100% sur mobile)
• ✅ Layout flex adaptatif pour petits écrans
• ✅ Tailles de police adaptées

À tester :

• Vérifier le comportement sur différents appareils mobiles
• Tester le clavier virtuel (focus, scroll)
• Valider les gestes tactiles si nécessaire

1.4 Amélioration UX (Priorité : Moyenne)

Statut : ✅ Implémenté (améliorations possibles)

Fait :

• ✅ Bouton "Se connecter" clair et visible (style primary)
• ✅ Gestion de l'affichage/masquage de l'iframe selon l'état
• ✅ Indicateur de statut de connexion avec couleurs (accepted/rejected/pending)
• ✅ Messages d'erreur avec raison du refus
• ✅ Interface "connecté" avec informations utilisateur
• ✅ Styles améliorés (couleurs, transitions, bordures arrondies)

Améliorations possibles (optionnel) :

• Loading states plus visibles pendant la vérification
• Guide utilisateur pour le premier login
• Messages d'aide contextuels

---

2. userwallet

2.1 Validation des écrans login (Priorité : Haute)

Statut : À valider avant implémentation
Référence : features/userwallet-ecrans-login-a-valider.md, RESTE_A_FAIRE.md (§ 1.1)

Action requise : Tester les écrans login existants et valider leur fonctionnement sur PC et mobile.

Écrans à valider :

• Sélection service / sélection membre
• Construction du chemin login
• Message de login à valider
• Collecte signatures mFA
• Publication
• Vérification locale + résultat

2.2 Notifications relais pour mobile (Priorité : Haute)

Statut : Partiellement implémenté
Référence : RESTE_A_FAIRE.md (§ 1.2), 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 :

1. Notifications push (si extension mobile)

   • Réagir aux événements push du relais pour savoir quel hash fetch
   • Implémenter un mécanisme de notification (Service Worker, Web Push, etc.)

2. Fetch automatique des données

   • Une fois le hash connu (via notification ou autre) : 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

3. Optimisation pour mobile

   • Réduire les appels réseau inutiles
   • Gérer les reconnexions réseau
   • Optimiser la collecte de signatures sur mobile (batterie, données)

Fichiers concernés :

• userwallet/src/services/relayNotificationService.ts
• userwallet/src/hooks/useRelayNotifications.ts
• userwallet/src/components/LoginCollectShare.tsx

2.3 Responsive design mobile (Priorité : Moyenne)

Statut : À vérifier et améliorer

Ce qui manque :

1. Interface responsive

   • Vérifier que tous les écrans login sont utilisables sur mobile
   • Adapter les formulaires pour petits écrans
   • Gérer le clavier virtuel (focus, scroll)

2. UX mobile

   • Gestes tactiles (swipe, etc.)
   • Tailles de boutons adaptées au tactile
   • Feedback visuel pour les actions

3. Performance mobile

   • Optimiser le chargement initial
   • Réduire la consommation mémoire
   • Gérer les limites de stockage IndexedDB sur mobile

---

3. service-login-verify

3.1 Intégration dans website-skeleton (Priorité : Basse)

Statut : Déjà intégré et fonctionnel

Fait :

• Package service-login-verify intégré dans website-skeleton
• Utilisation de verifyLoginProof, NonceCache, buildAllowedPubkeysFromValidateurs
• Instance de NonceCache créée et utilisée
• Construction des clés autorisées depuis les validateurs
• Vérification des preuves reçues

Note : L'intégration est complète et fonctionnelle. Aucune action requise.

3.2 Persistance du NonceCache (Priorité : Basse - Optionnel)

Statut : Actuellement en mémoire uniquement
Référence : RESTE_A_FAIRE.md (§ 2.1)

Description : Le NonceCache actuel est en mémoire avec TTL configurable. Une persistance optionnelle (IndexedDB, localStorage, etc.) peut être ajoutée si nécessaire pour éviter les rejeux après redémarrage du service.

Action requise : Implémenter uniquement si besoin de persistance entre redémarrages du service.

---

4. api-relay

4.1 Support notifications push pour mobile (Priorité : Moyenne)

Statut : À vérifier

Ce qui manque :

1. Notifications push (optionnel)

   • Si support Web Push : endpoint pour s'abonner aux notifications
   • Envoyer des notifications quand de nouveaux messages/signatures/clés sont disponibles
   • Gérer les abonnements par hash ou par service

2. Optimisation pour mobile

   • Réduire la taille des réponses
   • Support de la compression
   • Pagination pour les grandes listes

Note : Le modèle actuel est pull-only (GET). Les notifications push sont optionnelles mais amélioreraient l'expérience mobile.

---

Synthèse par priorité

✅ Complété dans website-skeleton

1. ✅ website-skeleton : Envoi du contrat au UserWallet (1.1)
2. ✅ website-skeleton : Gestion de session utilisateur (1.2)
3. ✅ website-skeleton : Interface responsive mobile (1.3)
4. ✅ website-skeleton : Amélioration UX (1.4)

Priorité Haute (Blocant pour login fonctionnel)

1. userwallet : Validation des écrans login (2.1) - À valider par tests

Priorité Moyenne (Améliore l'expérience)

2. userwallet : Notifications relais pour mobile (2.2)
3. userwallet : Responsive design mobile (2.3) - À vérifier
4. api-relay : Support notifications push (4.1) - Optionnel

Priorité Basse (Optionnel)

5. service-login-verify : Persistance NonceCache (3.2)

---

Workflow de login complet (cible)

Sur PC

1. Utilisateur ouvre website-skeleton
2. Clique sur "Se connecter" (ou iframe s'affiche automatiquement)
3. Iframe UserWallet s'affiche
4. website-skeleton envoie le contrat via postMessage à l'iframe
5. UserWallet reçoit le contrat et met à jour le graphe
6. Utilisateur sélectionne le service et le membre
7. UserWallet construit le challenge et collecte les signatures
8. UserWallet publie la preuve sur les relais
9. UserWallet envoie login-proof au parent via postMessage
10. website-skeleton vérifie la preuve avec service-login-verify
11. Si acceptée : session ouverte, iframe masquée, interface "connecté" affichée
12. Si refusée : erreur affichée, possibilité de réessayer

Sur Mobile

1. Utilisateur ouvre website-skeleton (responsive)
2. Clique sur "Se connecter"
3. Iframe UserWallet s'affiche (adaptatif, responsive)
4. Même workflow que PC
5. Différence : Notifications push pour informer des nouvelles signatures disponibles (si implémenté)

---

Notes importantes

• Les éléments marqués "À valider" nécessitent une validation explicite avant implémentation.
• website-skeleton a déjà une intégration de base fonctionnelle (iframe, vérification, écoute messages).
• Le package service-login-verify est déjà intégré et fonctionnel dans website-skeleton.
• Les points bloquants principaux sont : l'envoi du contrat à l'iframe et la gestion de session.
• Les écrans login de userwallet sont en place mais nécessitent validation.
• Les notifications push sont optionnelles mais amélioreraient l'expérience mobile.

---

Références

• features/userwallet-contrat-login-reste-a-faire.md
• features/userwallet-ecrans-login-a-valider.md
• features/service-login-verify.md
• RESTE_A_FAIRE.md
• website-skeleton/src/main.ts : exemple d'intégration complète
• userwallet/docs/specs.md : spécifications complètes
• service-login-verify/README.md : documentation du package