Mise en place d'une première interface de connexion (sans DB - comptes fixes) #61

New Issue

florian_briand · 2024-09-01T12:49:49+02:00

florian_briand commented

2024-09-01 12:49:49 +02:00

Maquette à venir

Ce ticket correspond à une implémentation "naïve", sans base de donnée, avec des comptes et mots de passe en dur.

Gestion de l'état initial non-connecté (popup obligatoire de connexion ? mode déconnecté ?)
Accès à la connexion / changement de compte / déconnexion
Sélection du compte
Authentification (règles MDP à définir)
Navigation au clavier

Maquette à venir Ce ticket correspond à une implémentation "naïve", sans base de donnée, avec des comptes et mots de passe en dur. - [x] Gestion de l'état initial non-connecté (popup obligatoire de connexion ? mode déconnecté ?) - [x] Accès à la connexion / changement de compte / déconnexion - [x] Sélection du compte - [ ] Authentification (règles MDP à définir) - [x] Navigation au clavier

florian_briand added the

enhancement

module/frontend

labels 2024-09-01 12:49:49 +02:00

florian_briand added this to the 0 - POC project 2024-09-01 12:49:49 +02:00

florian_briand self-assigned this 2024-09-01 12:50:10 +02:00

florian_briand commented

2024-09-01 13:25:20 +02:00

Où conserver les "états" de notre interface ? En particulier, présentement, sur la connexion utilisateur.

Option 1 : on le gère totalement côté serveur

Il y a un stockage côté serveur (en DB ou en RAM, peu importe) des états de l'interface, qui permet au moteur web (App) d'adapter le rendu de l'interface renvoyée au client à la situation
par exemple : tu te connectes avec User1, ça vient updater une info, côté serveur, que c'est User1 qui est connecté et ça renvoie une interface adaptée à User1 et respectant ses droits

Avantages

C'est une approche assez "naïve" et donc probablement + simple d'implémentation au début

Inconvénients

Le multi-session devient + galère à gérer (mais pas sûr qu'on en ait besoin)
Ça délègue toute la gestion d'état au serveur, je crains (mais sans aucune certitude) que ça ne soit un frein le jour où on souhaite faire des trucs avec des états côté client (pour des bouts d'interface + interactifs, par exemple)

Option 2 : on le gère à travers une approche plus "stateless"

On stock l'état côté client, dans un token sécurisé (JWT) qui est transmis au serveur à chaque requête ; son rendu d'interface s'adapte donc à l'état qui lui est fournit mais n'a pas de connaissance intrinsèque de l'état de son/ses clients
par exemple : tu te connectes avec User1, le serveur te renvoie un JWT (non modifiable côté client) qui contient diverses infos (statut de connexion, droits ...)

Avantages

C'est une approche "très standard" dans l'univers web, qui propose donc plein de librairies utilitaires pour faciliter ce genre de choses ; ça ouvre la porte d'usages avancés sans devoir re-inventer la roue
Ça permet "naturellement" le multi-session : plusieurs clients, avec chacun leur session, connecté à un même serveur (mais on ne semble pas trop avoir besoin d'une telle feature)

Inconvénients

C'est un chouilla + lourd à mettre en place, même si ça devrait, à priori, se limiter à l'usage de librairies côté Axum et côté HTML

Où conserver les "états" de notre interface ? En particulier, présentement, sur la connexion utilisateur. ## Option 1 : on le gère totalement côté serveur - Il y a un stockage côté serveur (en DB ou en RAM, peu importe) des états de l'interface, qui permet au moteur web (App) d'adapter le rendu de l'interface renvoyée au client à la situation - par exemple : tu te connectes avec User1, ça vient updater une info, côté serveur, que c'est User1 qui est connecté et ça renvoie une interface adaptée à User1 et respectant ses droits ### Avantages - C'est une approche assez "naïve" et donc probablement + simple d'implémentation au début ### Inconvénients - Le multi-session devient + galère à gérer (mais pas sûr qu'on en ait besoin) - Ça délègue toute la gestion d'état au serveur, je crains (mais sans aucune certitude) que ça ne soit un frein le jour où on souhaite faire des trucs avec des états côté client (pour des bouts d'interface + interactifs, par exemple) ## Option 2 : on le gère à travers une approche plus "stateless" - On stock l'état côté client, dans un token sécurisé (JWT) qui est transmis au serveur à chaque requête ; son rendu d'interface s'adapte donc à l'état qui lui est fournit mais n'a pas de connaissance intrinsèque de l'état de son/ses clients - par exemple : tu te connectes avec User1, le serveur te renvoie un JWT (non modifiable côté client) qui contient diverses infos (statut de connexion, droits ...) ### Avantages - C'est une approche "très standard" dans l'univers web, qui propose donc plein de librairies utilitaires pour faciliter ce genre de choses ; ça ouvre la porte d'usages avancés sans devoir re-inventer la roue - Ça permet "naturellement" le multi-session : plusieurs clients, avec chacun leur session, connecté à un même serveur (mais on ne semble pas trop avoir besoin d'une telle feature) ### Inconvénients - C'est un chouilla + lourd à mettre en place, même si ça devrait, à priori, se limiter à l'usage de librairies côté Axum et côté HTML

florian_briand referenced this issue

2024-09-22 19:06:14 +02:00

Remplacement de la stack HTMx #65

florian_briand referenced a pull request that will close this issue

2024-09-24 01:14:00 +02:00

Ajout d'un parcours utilisateur⋅ice de connexion / déconnexion #67

florian_briand closed this issue

2024-09-24 12:57:34 +02:00

florian_briand referenced this issue from a commit

2024-09-24 12:57:35 +02:00

Merge pull request 'Ajout d'un parcours utilisateur⋅ice de connexion / déconnexion' (#67) from feat/61_add_login_workflow into main

Sign in to join this conversation.