Authentification avec Redis, express-session, Passport

00:00 Dans les vidéos précédentes, nous avons configuré ensemble un mono-Ripo qui nous permet d'utiliser Remix avec Nest JS pour pouvoir bénéficier de tous les avantages de remix ainsi que ceux de Nest JS. Dans cette vidéo, nous allons implémenter ensemble l'authentification de nos utilisateurs. Nous allons donc commencer par configurer l'ORM Prizma qui va nous permettre de communiquer avec une base de données. Ensuite, nous pourrons développer les fonctionnalités que l'on voit dans absolument toutes les applications, à savoir création de compte, mot de passe oublié, connexion du compte, mais nous allons également ajouter des fonctionnalités avancées. Si on regarde ensemble l'intégration du design sur figma, on peut voir qu'il y a une connexion par email et mot de passe et donc une connexion standard, mais nous avons également la possibilité de créer un compte avec Facebook et avec Apple.

00:48 Nous implémenterons la connexion avec Apple et avec Facebook dans une prochaine vidéo. Par contre, nous avons aussi une dernière que nous allons implémenter, c'est la saisie d'un code à usage unique reçu par SMS. Dans notre cas, on enverra le code par email, mais le principe reste le même. Pour continuer le projet, il suffit de vous rendre sur ce repository GitHub qui s'appelle remix tiret net j s ramu le repos et d'accéder à la branche qui s'appelle zéro trois tiret puisqu'on va partir de là pour continuer avec l'authentification. Pour la télécharger, il suffit de cliquer ici sur code et de copier cette commande-là et ensuite d'ouvrir votre terminal et de faire un guide clone et de coller cette commande comme ceci.

01:27 Maintenant, vous pouvez faire un CD de remix NSJS mono repos comme ceci et ensuite, on peut voir qu'on commence dans la branche main. Donc, il nous suffit de faire un git checkout zéro trois tiret dading pour nous retrouver sur cette branche qui est bien avancée par rapport à la branche main. On ouvre ensuite le projet dans vscode et on lance la commande NPM install pour installer toutes les dépendances. Une dernière chose à faire, c'est de faire un git checkout tiret b pour créer une nouvelle branche, on va appeler zéro quatre authentification comme ceci. Nous pouvons maintenant lancer le projet avec un NPM rendeve comme ceci nous allons ensemble mettre en place l'authentification par mot de passe.

02:04 Déjà la première chose qu'on peut faire, c'est d'aller sur la doc de net ch s et de taper authentification pour voir ce qu'il recommande. Tout en bas de la page, il nous parle de l'intégration avec la librairie passeport, qui est la librairie la plus populaire de Node g s et qui permet d'intégrer l'authentification à notre application. Il nous demande ensuite de cliquer sur ce chapitre, ce qui nous redirige sur une page dédiée à l'intégration de passeport et nous avons déjà les premières étapes à exécuter dans notre projet, ça va être de télécharger passeport avec NPM. On retourne donc dans notre projet, ici, on peut fermer ces deux pages, on va kill le terminal et on va faire un CD dans backend cette fois, parce que ça va être Nest JS notre serveur qui va se charger de l'authentification. À l'intérieur de backend, on va donc lancer la commande n p m'install de ces trois librairies.

02:50 Maintenant, si on se rend dans le package JSON du Backend, on retrouve les trois librairies qui viennent d'être installées. On a donc l'intégration NSJS avec passeport, on a aussi la librairie passeport en elle-même et on a la librairie passeport local qui permet d'utiliser un user name et un password pour s'authentifier. En descendant plus bas dans cet article, on peut voir qu'on a login root ici qui nous permet de mettre en place l'authentification de notre utilisateur. On déclare donc un contrôleur dans le FGS qui déclare une route post à l'u r l hausse slash login et qui utilise un guard. Le guard, c'est le os guard de la librairie passeport.

03:28 On va clairement copier ce morceau de code et on va créer ce contrôleur tout de suite dans notre application. On se rend donc dans notre code backend, dans le fichier SRC comme ceci et on va créer un nouveau dossier qu'on va appeler hausse et à l'intérieur de ce dossier, nous allons créer un nouveau fichier qu'on va appeler hausse point contrôleur point ps dans ce fichier nous allons coller le code que nous venons de copier nous importons donc Osguard depuis Nest JS passeport et nous importons aussi le décorateur usegards depuis Nest JS nous avons donc cette méthode qui s'appelle login et nous allons changer son type ici on va pas prendre l'objet request on va prendre à la place le décorateur rec qui est exactement le même ça va nous permettre de typer cette request par le type request que nous allons importer depuis express comme ceci maintenant on peut voir on est censé avoir un utilisateur dans la request bien sûr des scripts n'est pas tout à fait d'accord avec ça Ce qu'on peut faire par contre, c'est de faire un console log de l'objet rec point user au lieu de renvoyer cet utilisateur. Et maintenant, nous allons essayer de nous connecter.

04:33 Effectivement, on utilise le décorateur useguard. Le décorateur useguard est utilisé pour déclarer un garde. Et le garde, c'est un middleware spécial qui va marquer cette route comme étant une route utilisant l'authentification. Ce garde va donc ajouter un morceau de logique particulier qui va nous permettre d'authentifier notre utilisateur. Pour que ça soit plus clair, nous allons créer un autre fichier dans le dossier hausse que nous allons appeler hausse point module point ts.

05:01 Nous allons copier le code du fichier app module dans le hausse module en retirant les contrôleurs de remix et en renommant le module en haut module comme ceci et nous allons importer un module ici dans les imports et ce module ce sera le passeport module. Bien sûr, je m'inspire de la documentation de NetsJS pour importer ce module un petit peu plus haut ici. Il nous était demandé d'importer le module passeport et d'importer également une locale stratégique ici. Et c'est cette stratégie qui va ajouter la propriété user dans notre Request. Si on remonte encore plus haut dans l'article, ici, nous avons toute la logique de notre local stratégie.

05:40 On peut d'ailleurs la copier comme ceci et on peut retourner dans notre application dans le dossier hausse pour module pour créer un nouveau fichier que nous allons appeler local point stratégie point ts. Et nous allons maintenant copier ce code-là. Nous importons donc le service d'authentification, mais pour le moment, il n'existe pas. Donc ce qu'on peut faire, c'est qu'on peut renvoyer un utilisateur imaginaire. On va donc faire un return avec une ID à un par exemple.

06:05 Nous allons également ajouter un console log, console loguer le username et le password comme ceci et nous allons retirer le type for à cette méthode, bien que ça ne change pas grand chose parce qu'on ne va pas l'appeler directement. Comme le service Os Services, on n'a pas besoin du coup d'injecter le service Os Services parce qu'on ne l'a pas encore créé dans ce pour cette application, on va le créer plus tard. Maintenant, on a une petite erreur, Typescript à ce niveau-là. Il n'arrive pas à trouver la déclaration de modules pour passeport local. Il nous conseille de télécharger la librairie arobase tapes slash passeport tiret local.

06:38 Ce qu'on va faire, c'est qu'on va quand même aller sur NPMGS et rechercher la librairie passeport tiret local et on peut voir qu'il possède bien une déclaration de module et que la librairie s'appelle bien arobase tips slash passeport tiret local. On va donc copier cette commande dans notre terminal comme ceci et on n'oublie pas le tiret d pour dire qu'on veut la télécharger en tant que dev n c. Voilà, ça a été téléchargé et on peut voir que notre erreur est partie. On arrive maintenant à importer le type de la stratégie passeport. Ce qu'on peut faire maintenant, c'est ajouter un deuxième paramètre à la fonction passeport stratégie ici pour lui assigner le nom de notre stratégie.

07:18 Par défaut, elle possède le nom de local comme ceci et c'est en la nommant local comme ceci que dans notre hausse contrôleur, NSJS sera capable de la retrouver ici parce qu'on fait appel à une stratégie portant le même nom, c'est-à-dire local. Maintenant, on peut voir qu'on a également plus d'erreurs de type dans notre objet request et c'est lié au fait qu'on ait téléchargé les types de la librairie passeport locale. Maintenant, si on passe la souris sur le request point user, on peut voir que ça peut continuer soit en express point user, soit undefined. Maintenant, on doit importer ce fichier local stratégie dans notre fichier module ici. Donc, on va l'importer en tant que provider comme ceci, en apportant local stratégie et on peut même ajouter un morceau de logique à notre module passeport en appelant la méthode register et en modifiant les trois propriétés que nous retrouvons ici.

08:10 On va dire que la défault stratégie s'appelle locale, et ça, c'est dans le cas où on aurait nommé notre stratégie différemment. Ensuite, la propriété qui est créée au moment de créer un utilisateur va s'appeler user et ensuite les sessions prend un booléen et nous, on a envie de stocker ces informations-là dans une session. On va donc mettre cette propriété à trous. Maintenant, on va modifier une dernière déclaration avant de faire une tentative de connexion et c'est la logique de notre hausse garde à ce niveau-là. Pour avoir encore plus de contrôle, on retourne dans la documentation de net.

08:43 Js et on clique sur le menu Extende in guards ici et nous avons un morceau de code que nous allons analyser tout de suite. Nous allons également le copier et en gros, ça nous permet de déclarer une classe qui s'appelle dans l'exemple JWT Osguard et qui fait un extende du garde JWT. Il utilise donc une méthode qui s'appelle can Activate ici, qui nous permet de rajouter une logique pour authentifier l'utilisateur. Et ensuite, il y a également une autre méthode qui s'appelle Handle request qui nous permet d'ajouter un morceau de logique. Par exemple, si on essaie d'accéder à la route qui utilise ce garde, mais sans avoir fourni d'utilisateurs.

09:18 Donc, on va copier ce morceau de code et on va retourner dans VS Code ici et nous allons créer un dernier fichier qu'on va appeler local tiret hausse point garde point ts. Et nous allons maintenant copier toute cette logique et nous allons la refacto. On n'utilise donc pas la stratégie JWT, on utilise la stratégie locale. Donc on renomme cette classe et on va préciser que notre hostgard s'appelle maintenant local. Alors pourquoi a-t-on besoin de redéfinir notre stratégie C'est pour utiliser le super login ici qui va nous permettre de sauvegarder les informations de l'utilisateur dans la session.

09:52 On peut voir que cette méthode a besoin de la request. Donc la première chose que nous allons faire, c'est de récupérer la request à partir du contexte en faisant un contexte et en appelant la méthode switch http, puis la méthode get request comme ceci. Maintenant, on est dans la request et à tout moment, on peut récupérer les informations de l'utilisateur, par exemple le user name, le mot de passe, et caetera. Ensuite, il nous suffit d'appeler cette méthode-là qui s'appelle super point login et de lui passer la request. C'est une promesse, donc on va la weight comme ceci et comme on va la weight, on va marquer la méthode can activate comme étant asynchrone et on va fortement la typer pour dire que ça va retourner un booléen sous forme de promesses.

10:34 Maintenant, on peut voir aussi que la méthode can activate est également une promesse ou alors un observable, donc on va la et on va ensuite dire qu'on la return en tant que booléen comme ceci. Maintenant, il faut savoir quelque chose. Ici, nous avons la méthode can activate et au lieu de la renvoyer, nous allons la sauvegarder dans une variable qui va s'appeler can be activated par exemple parce que c'est seulement si la méthode peut être activée que nous allons connecter l'utilisateur avec la méthode login. Effectivement, la méthode canactivate va récupérer notre request et va exécuter ce code là, donc le handle request, ce qui va nous permettre de déterminer s'il y est bien une erreur ou alors qu'il n'y ait pas d'utilisateur dans notre body. S'il n'y a pas d'utilisateur dans le body, alors nous allons une nouvelle erreur.

11:22 Sinon, nous allons renvoyer l'utilisateur. Et à ce niveau-là, on peut maintenant, de manière sécurisée, connecter l'utilisateur et donc sauvegarder ces informations dans la session. Si on n'utilise pas ce morceau de code, on connectera l'utilisateur avec succès, mais ces informations ne seront pas sauvegardées dans la session. Maintenant, on n'oublie pas à la fin de renvoyer le booléen can be activated parce que ça va nous permettre de dire à notre garde ici qu'il peut laisser passer la request. Maintenant, on a terminé de modifier le fichier local aux gardes, donc on peut retourner dans le module et nous pouvons maintenant l'importer en tant que provider comme ceci.

11:57 On peut maintenant retourner dans le fichier os en controller et nous allons supprimer cette déclaration et la remplacer par notre local osguard comme ceci. Maintenant, dans la documentation ici, il y a une partie qui s'appelle request scope strategies qui nous indique qu'on peut ajouter ce props, pass rec ou call back et qu'on peut le mettre à trop. Et c'est très intéressant d'activer cette option. Elle s'ajoute donc dans le local stratégie ps et c'est. Donc on va retourner dans notre fichier local point stratégie et dans notre constructeur, dans la méthode super, nous allons activer cette option qui s'appelle pass request to call back, ce qui va nous permettre par la suite de récupérer notre request dans la méthode validate ici.

12:38 Cependant, ça va chambouler l'ordre de nos paramètres ici parce qu'on peut voir que la méthode validate récupérait un username et un password. Maintenant, elle va d'abord récupérer notre objet request qu'on va donc pouvoir typer comme étant une express point request comme ceci. Maintenant, si on retourne une dernière fois dans cette documentation, on pouvoir qu'il nous donne un conseil pour toujours utiliser cette méthode super. Ça nous permet de customiser la manière dont on utilise la stratégie Lastport. Effectivement, par défaut, on utilise une propriété user name et une propriété password ici.

13:11 Et on peut le voir ici, on récupère un user name. Mais dans notre cas, nous, on va plutôt avoir besoin d'utiliser un email. Donc, dans notre formulaire de connexion, si on retourne sur l'intégration ici, on peut voir qu'on a deux champs. On a bien le password, mais on a un champ qui s'appelle email. Alors, on aurait deux choix, soit on pourrait nommer notre formulaire user name et qu'on tiendrait un email, mais ce ne serait pas ouf et on aurait besoin de documenter ce changement aux côtés des développeurs.

13:35 Soit si on retourne dans la doc, on peut voir qu'on peut modifier la propriété, le nom de la propriété UserName. Et ici, par exemple, on indique que la propriété UserName, c'est en fait un email. Donc, on va ajouter ce deuxième paramètre, notre méthode super, comme ceci. Et maintenant, on peut renommer notre champ ici que nous allons appeler maintenant email. Si on n'avait pas rajouté cette option, si on fait maintenant un post dans notre méthode ici, ça va frau une erreur si la propriété username n'existe pas.

14:03 Maintenant, ça ne va plus être le cas. Ça va regarder s'il existe une propriété email et une propriété password. Et si c'est, et si c'est le cas, alors ça va laisser passer et on pourra exécuter cette requête. Maintenant, nous allons tester cette intégration et nous allons ouvrir la librairie Postman et nous allons créer une nouvelle request, il sera donc une request http et qui va contacter l'url localhost trois-mille et la route hausse slash login. On va donc la sauvegarder comme ceci et cette méthode sera donc une méthode poste et elle va prendre dans le body un email et un mot de passe.

14:39 On va donc dire que ça renvoie du RAW comme ceci et ça sera du RAW json. On va donc ouvrir les moustaches et nous allons ajouter une première propriété qu'on va appeler email. On va mettre par exemple Virgile et une deuxième propriété qu'on va appeler password et on va mettre un deux trois comme ceci. Maintenant, on va retourner sur notre application et nous allons lancer le terminal. Pour ce faire, on va faire un cd double point remonter d'un cran dans notre Molo repo et nous allons maintenant lancer la commande npm run dev.

15:06 Ici, on peut voir qu'on a donc quelques petites erreurs de type au niveau de notre hausse garde. C'est pas grave, pour le moment on peut utiliser un TS expect erreur et mettre un message par exemple aux dates laader et nous allons vérifier que notre contrôleur a bien été instanciés dans le terminal. On peut voir donc que le module app est initié et que le module remix controller est initialisé. Mais c'est tout, ça veut dire que notre contrôleur hausse n'a pas été initialisé et c'est normal, on ne l'a pas encore importé, donc on peut retourner dans notre app module ici et nous pouvons importer notre contrôleur. Mais attention, il y a une erreur qu'il est possible de faire, c'est d'importer le haut contrôleur comme un deuxième paramètre dans ce tableau de dépendance.

15:46 Et je vais vous dire pourquoi c'est un problème. Effectivement, notre remix contrôleur s'exécute sur absolument toutes les routes et Nest GF va définir les contrôleurs dans l'ordre. C'est-à-dire qu'on doit déclarer notre remix contrôleur en dernier après avoir déclaré toutes nos routes Nest JS. Parce que si on le déclare en premier, ça signifie que la méthode hausse login sera gérée par remix et non pas par net JS. Elle sera gérée par net JS, mais elle sera gérée par cette méthode de contrôleur ici qu'on a appelé et c'est et c'est pas ce qu'on veut.

16:16 Nous, on a envie qu'elle soit gérée par cette route là que nous venons de créer. Donc, ce qu'on peut faire, c'est qu'on peut déjà renommer notre contrôleur en hausse contrôleur comme ceci et on peut maintenant retourner dans notre fichier module et nous allons l'importer, mais nous allons également le déplacer pour qu'il soit déclaré avant le remix contrôleur. Maintenant que les changements ont été effectués, on peut revoir les log de terminale et on peut voir que le module app module vient d'être initialisé et on a d'abord déclaré un host controller et une route post sur host slash login. Et ensuite, on déclare le remix controller sur absolument toutes les autres routes. C'est plutôt pas mal.

16:53 Donc maintenant, on va retourner sur passeman ici et on va tenter de lancer cette requête. On va donc faire send et là on peut voir qu'on a une erreur qui s'appelle internal server erreur cinq cents. Si on retourne dans notre terminal, on peut voir qu'on a une erreur unown authentification stratégie locale. Et c'est parce qu'on a oublié sûrement qu'on importe. En fait, on a oublié d'importer notre hausse module qui importe le module passeport et notre stratégie locale ainsi que notre hausse garde.

17:21 Ce module s'appelle donc hausse module, nous allons donc l'importer dans le module principal, donc dans le app point module, comme ceci. Maintenant, ça a actualisé et on peut voir que ça a donc importé le fichier host module avant le fichier app module. Ce qui est plutôt cool, on peut retourner sur pass man et on peut relancer notre requête. On la lance et cette fois on a une autre erreur, on a un anotherised quatre cent un, Ce qui signifie qu'on n'a pas le droit d'accéder à cette route. Si on retourne dans notre application, on peut voir qu'on a des logs, donc c'est plutôt mon fil.

17:50 Ça log notre request ici et on peut voir qu'il y a plein d'informations dans la session, notamment l'url, la méthode, le client, mais une chose est sûre, ce qui a été logué, ce n'est pas le request. User parce que notre garde a trop une erreur. Ici, ce anosorised erreur quatre cent un signifie que dans notre local osguard, ça a throw cette erreur-ci. On peut voir que le message d'erreur par défaut, c'est un statut qui est égal à quatre cent un. Pour en avoir le coeur net, on peut mettre comme message par exemple, vous n'avez pas le droit d'accéder à cette page.

18:25 Maintenant on retourne sur pass man et on réexécute la requête, on peut voir que cette fois, on a un message d'erreur un peu plus clair, vous n'avez pas le droit d'accéder à cette page. On a ce message d'erreur parce que l'utilisateur n'est pas défini. Ce qu'on peut faire du coup, c'est faire un console log de notre utilisateur et de notre erreur. Et on va également en seul logger les infos. On va maintenant réexécuter cette méthode sur Postman comme ceci et on retourne maintenant sur notre application et on peut voir qu'on a un user qui est à false et une erreur qui est annule et une info qui s'appelle miss in credentials.

18:57 Et juste avant, nous avons le console log de notre objet request et c'est ce console log là qui est exécuté. Ça signifie que à cet endroit-là, on exécute la méthode can be activated et neuf g s nous dit qu'il ne peut pas, on ne peut pas activer notre session d'utilisateur. Ce qu'on peut faire, c'est qu'on peut extraire le body de notre request pour voir s'il existe bien les propriétés email et password. Maintenant, on va donc console loguer le body dans la request. Maintenant, on n'a pas le type de notre request ici, on peut voir que c'est typé eni, mais nous on sait qu'on utilise express donc on va ajouter le type générique ici dans la méthode get request qui accepte un type générique et nous allons mettre que c'est une express point request comme ceci.

19:41 Et là on peut voir qu'on aurait eu une erreur en appelant la méthode request point body parce que cette propriété n'existe pas. Alors, qu'est-ce qui est présent dans notre request On a donc hausse info, is authenticated, is anauthenticated, login, logout, login, logout. Et on a la propriété user, bien sûr. En fait, je me rends compte que je me suis trompé au niveau du type générique express point request. On va à la place utiliser juste la request qu'on va importer depuis express comme ceci et on peut voir si on active l'autocomplettion qu'on a beaucoup plus de propriétés, compris le body qu'on voulait regarder pour voir ce qui se trouve dans le body.

20:16 Maintenant qu'on consacre notre body, on peut retourner sur Pastman à cet endroit là et relancer notre requête et si on retourne maintenant ici on peut voir qu'on a la même erreur il faut faire un console log de undefined ce qui signifie qu'il n'y a pas de body dans notre request. Quand j'avais discuté à Antoine, le créateur de cette stack à l'époque, c'est-à-dire que la méthode serait parfaitement fonctionnelle avec une application et avec un navigateur normal comme celui-ci, mais que Postman déclencherait une erreur parce qu'il ne possède pas de sessions. Effectivement, si on retourne dans v s code et qu'on retourne dans notre hausse module ici, on a précisé qu'on voulait activer les sessions. Si on retourne maintenant dans notre local Osguard, ce qu'on va faire pour le moment pour continuer d'implémenter l'authentification, c'est que nous allons hardcoder les propriétés de connexion. Pour ce faire, il nous suffit de rajouter artificiellement un audi à notre request et ensuite de rajouter chacune des propriétés.

21:13 Par exemple, un email qui sera égal à Virgile et un password qui sera égal à un, deux, trois comme ceci. Maintenant, si on actualise la page et qu'on soumet à nouveau notre request, ce qui va se passer, c'est que on va donc exécuter ce code là, puis on va exécuter la méthode super point canactivate qui va on aura donc le même log sauf que cette fois le sera défini ça ne pourra plus trop cette erreur. Ce que ça va faire à la place c'est que ça va return le user et ensuite nous allons le login et le sauvegarder dans la session. Faisons-le tout de suite, donc retournons sur Postman et exécutons maintenant notre request comme ceci. Là, on peut voir que le message d'erreur est différent.

21:54 Si on retourne sur neuf pour voir un long message d'erreur, cette fois on a des log et ces log là, ils ont été déclarés en dessous. C'est-à-dire là nous avons la méthode donc console loguer l'utilisateur, l'erreur et l'info et l'utilisateur est bien présent cette fois parce qu'il a l'ID qu'on lui a assigné, c'est-à-dire l'ID de un. Mais ce morceau de logique, on peut le retrouver dans la local stratégie à ce niveau-là. Ce qui signifie que la méthode validate de notre stratégie a été exécutée avant la méthode Handle request. En gros, ce qui se passe, c'est qu'on a donc défini une propriété email et password dans notre méthode canactivate qui est la première méthode de notre garde.

22:36 Il vérifie donc si on peut autoriser l'accès à la route. Ici, on récupère donc un email et un mot de passe et on renvoie une ID qui est égale à un, mais on peut envoyer n'importe quoi. On peut envoyer par exemple un token JWT ou n'importe quoi qui nous permet d'identifier une session de l'utilisateur. Et après cette validation, on retourne ici dans cette méthode et on renvoie l'utilisateur vient d'être créé, en l'occurrence avec l'ID de un. Puis, c'est censé de l'autoriser à accéder à cette méthode-là qui par la suite va effectuer un console log de request point user.

23:09 On peut même rajouter ça dans un objet pour dire que c'est un request user, ce qui nous permettra d'identifier ce console log plus tard. Mais en réexécutant la requête sur passman, on peut voir qu'on a une erreur et cette erreur nous dit que login sessions require session support, did you forget to use express tiret session middleware. Effectivement, on a oublié de télécharger cette librairie express tiret session et on en a besoin pour activer et sauvegarder les sessions des utilisateurs. Donc on va tout de suite retourner sur Chrome et nous allons télécharger express tiret session sur NPM ici en faisant un NPMI de express tiret session. Maintenant on retourne dans vscode et on va ouvrir un deuxième terminal, on va faire un cd de backend et on va installer express session.

23:53 Si on retourne sur Google, on peut voir que express session possède également les déclarations de type à cet endroit-là. Donc, on va également les télécharger. On va faire un NPMI deux arobase tapes session et on ne va pas oublier de rajouter le tiret d pour les télécharger en tant que dev deppenancer. Maintenant, si on retourne sur express session sur NPMGS, on peut voir qu'il y a une documentation qui va nous expliquer un petit peu comment cette librairie fonctionne. Ici, on peut voir qu'on a besoin de rajouter un middleware notre application.

24:24 Comme on utilise express avec NesGS, on va devoir faire un a point use et ainsi que la session actuelle et des propriétés particulières comme par exemple des cookies, le reset et le save un initialized. Ce qu'on va faire, c'est qu'on va tout de suite copier ce code, on va retourner dans v s code, dans le fichier main en t s à cet endroit-là et ici on a bien notre app avec lequel on peut faire notre app point use comme ceci, mais nous avons besoin d'abord de créer une session. On va donc importer la méthode depuis express et la session comme ceci et nous allons pour le moment conserver cette configuration. Si on scrolle tout en bas de la documentation, on peut voir qu'on a besoin d'utiliser express session avec des stores. Et ces stores servent à conserver les identifiants de notre session dans une base de données.

25:13 La question qu'on pourrait se poser, c'est est-ce qu'on en a besoin est-ce qu'on ne peut pas les sauvegarder dans la mémoire Si on retourne sur Postman et qu'on réexécute une requête, ici, on peut voir qu'on a de nouveau une erreur cinq-cents internal serveur erreur. Et si on retourne dans vscode et qu'on rouvre notre terminal à cet endroit-là, on peut voir qu'on a une nouvelle erreur, cette fois ce n'est pas la même qu'avant, cette fois elle nous dit Saled to serialized users into session. Ça signifie qu'on n'a pas ajouté le store pour sauvegarder notre session utilisateur. On peut utiliser le collecteur que l'on souhaite, celui qui a été le plus utilisé ici, c'est connect tiret release. On peut voir qu'il a deux-mille-huit-cents étoiles sur GitHub, c'est le plus populaire et c'est celui que nous allons télécharger.

25:55 Ils nous disent dans la documentation que nous avons besoin de le télécharger avec par exemple, Aerredis ou avec Redis. Donc, on va le faire tout de suite. On va télécharger ces trois librairies. On va retourner maintenant dans VS Code et on va rouvrir un terminal dans le backend donc on va refaire un cd backend et on va lancer cette commande NPM install de e o redis connect tiret redis et express tiret session qu'on avait déjà installé. Maintenant que c'est fait, on peut retourner sur la documentation ici et on peut voir qu'on peut importer le redis store avec cette commande-là.

26:29 Donc on va l'emporter tout de suite dans notre fichier main point t s comme ceci et ensuite nous devons créer un client redis qui va se connecter à notre base de données redis. Et enfin, à la fin dans notre middleware, nous ajoutons la clé store qui prendra comme valeur notre redis store. On copie donc d'abord ce code-là et on retourne dans v s code et nous allons le coller jusqu'ici. On utilise maintenant, Maintenant, on peut voir qu'on a une petite erreur au niveau de l'importation de io redis ici. Donc, on va se rendre sur MPM et nous allons chercher cette librairie.

27:00 Dans un nouvel onglet, on va taper I o redis et on peut voir dans la documentation ici qu'on peut importer redis avec un r majuscule depuis ayo redis. Et c'est en fait une classe qu'on instancie avec un new comme ceci. On va le faire tout de suite, on retourne dans notre code et au lieu du create client, on va appeler ça redis et le redis client, nous allons faire un new redis comme ceci. Maintenant, on peut voir que cette classe peut prendre plusieurs paramètres, notamment par exemple le host et le port. On voit que Copy.

27:29 Io me suggère les bonnes adresses. Dans notre cas, nous allons configurer deux nouvelles variables d'environnement, une pour le host et une autre pour le port. Mais ce qu'on peut faire sinon, c'est d'ajouter une url de connexion similaire aux bases de données, c'est-à-dire quelque chose comme redis double point redis double point soixante-trois soixante-dix-neuf, comme ceci. Et on pourra la passer en premier argument ici, et comme deuxième argument, on pourrait toujours spécifier notre objet d'option. Au final, on va plutôt faire comme ça, ça nous permet de déclarer une seule variable d'environnement au lieu de deux.

27:60 On va donc sauvegarder ça dans une variable en appelant ça redis url est égal à redis double point slash slash localhost double point soixante-trois soixante-dix-neuf qui est le port par défaut de redis, mais on va dire que ça prend cette valeur seulement si si la variable d'environnement qu'on va appeler Redis d'heure score URL n'est pas définie comme ceci. Maintenant, on va donc se connecter à cette url et nous allons commencer à configurer le store. Et le store, il a besoin du client redis pour sauvegarder toutes les sessions utilisateurs. On n'a pas besoin de préciser un préfixe comme celle-ci. Par contre, on peut préciser une TTL.

28:36 La TTL, c'est la time to gleeve, c'est-à-dire la durée de notre session. Par défaut, on peut mettre quatre-vingt-six mille quatre cents comme ceci parce que quatre-vingt-six mille quatre cents secondes est équivalent à un jour. Si on veut donc que la session reste active pendant trente jours, il nous suffit de multiplier ce chiffre par trente comme ceci. Maintenant qu'on a créé notre store, on va retourner sur NPM ici, sur le package connect tiret reelis et on peut voir à la suite de notre code qu'on déclare un store et ensuite on initialise un session storage. C'est-à-dire qu'on déclare un nouveau middleware qui va s'occuper de sauvegarder les sessions utilisateurs dans ce Eurylis store comme ceci.

29:14 Donc il nous suffit de copier ce morceau de code et on retourne maintenant dans notre projet et on l'ajoute comme ceci. Bien sûr, on ne peut pas l'ajouter au début. On a d'abord besoin de déclarer notre app, donc nous allons déplacer toute cette logique à l'intérieur de notre app. Après avoir lancé le serveur, ici nous allons coller notre logique, On va donc déclarer une url qui s'appelle redis url. On va s'y connecter avec un rediscline point connect et en cas d'erreur, on va bien sûr afficher les erreurs dans la console.

29:41 Ensuite, on va instancier le store qui va se connecter à cette base de données redis et ensuite on va associer notre store au store de la session qui est utilisé par le middleware express tiret session. Bien sûr, ce secret que nous retrouvons ici devrait être remplacé par un secret vraiment protégé qu'on va ajouter dans nos variables d'environnement. On va par exemple appeler appeler process point INV point session underscore secret comme ceci. Sinon, on va mettre par exemple un, deux, trois pour le moment. Maintenant, ce qu'on peut faire aussi dans ce middleware de session, c'est rajouter la propriété cookies pour conserver les informations de notre session dans les cookies.

30:19 Et cet objet prend plusieurs paramètres, par exemple une durée qui sera équivalente à trente jours et des permissions par exemple qui signifie que ce cookie sera strict ou long. Dans notre cas, on peut laisser l'axe pour l'instant et on peut également dire que notre cookie va être sécurisé avec le mot clé Secure ici. Maintenant si on rajoute le mot clé Secure, ça veut dire que seuls les navigateurs bénéficiant du certificat SSL pourront y accéder. C'est-à-dire, il faudra accéder au site en HTTPS comme ceci. Si un site essaye d'accéder au site en HTTP, il ne pourra pas s'identifier parce que les cookies ne lui seront pas renvoyés.

30:57 Ce mot clé là, si on met la souris sur cette propriété, on peut voir qu'il y a une documentation intégrée à VS Code. Ils nous disent par exemple que mettre secure 2 est l'option recommandée, par contre on a besoin d'activer le HTTPS. Évidemment, en environnement de développement, on ne pourra pas accéder à notre site en HTTPS. Donc nous allons désactiver ce cookie et le sécuriser conditionnellement si on est sur le serveur de prod. Par contre, il y a quelque chose qui est très intéressant ici.

31:22 Ici, ils nous disent que si on utilise par exemple un proxy et qu'on sécurise les cookies, on aura besoin de cette trust proxy dans express. Et si on clique sur readme, on peut voir qu'on peut ajouter le trusts proxy comme ceci avec cette ligne juste avant la déclaration de notre middleware. C'est ce que nous allons faire tout de suite pour la simple et bonne raison qu'on va utiliser un proxy effectivement quand on va mettre en prod, on va utiliser docker qui va servir de proxy pour notre application. Maintenant que c'est fait, on va pour le moment mettre le secure à false et nous allons maintenant installer redis. On va donc sur Google et on va taper install redis with docker comme ceci et nous avons plusieurs documentations.

32:02 Par exemple, la documentation officielle de Redis nous propose d'installer la Redis stack serveur ou alors la Redis stack comme ceci. Personnellement, je vais plutôt cliquer sur le deuxième lien parce que j'ai envie de télécharger l'image officielle de redis sur Docker hub. Malheureusement, sur ce site, il n'y a aucun lien. Donc, nous allons tout de suite accéder à Docker hub comme ceci et nous allons taper Redis. Et on peut voir qu'il y a donc un trustd content et si on clique dessus, on peut voir qu'on a l'image officielle de Docker de Redis qui a été téléchargée plus de un milliard de fois et qui a plus de dix mille étoiles.

32:35 Pour la télécharger, il nous suffit de faire un docker pool d'Euryllis, mais on ne va pas le faire tout de suite. On peut voir qu'il y a plusieurs versions d'Euryllis. Ce qu'on va faire, c'est qu'on va la télécharger directement avec docker. Donc, on va retourner dans notre base de code, on va fermer tous les fichiers et on va ouvrir le docker compose point dev. Maintenant, on peut voir qu'on a donc un service qui s'appelle mono repos underscore dev et qui contient notre logique métier, ça contient notre application NSGS et notre application remix.

33:03 À côté de ce service, nous allons rajouter un deuxième service que nous allons appeler redis underscore dev et ça sera ce service et dans ce service, nous allons télécharger l'image docker de redis. On va donc ajouter une image qui sera donc Redis double point latetest et si on n'est pas sûr de cette syntaxe, on peut tout de suite aller sur Google et taper Redis docker compose image comme ceci et cliquez sur cet article pour voir à quoi ressemble une déclaration de redis. Ici par exemple nous avons plusieurs mots clés comme l'ory start, le port, la commande et le volume. Donc on va copier tout ce morceau. On va effectivement restart l'instance Redis si jamais le crash.

33:44 Nous allons en local ouvrir les ports soixante-trois soixante-dix-neuf et les bindés au port soixante-trois soixante-dix-neuf de Redis et nous allons ajouter commande là pour lancer le serveur edis. Mais on va plutôt le faire avec cette syntaxe en tant que tableau d'instructions. Pour le moment, on va juste lancer le redis tiret serveur comme ceci. Faut savoir au niveau du volume qu'on aura besoin de bind un dossier sur notre serveur pour sauvegarder ces données. Parce que si on active aucun volume, à chaque fois qu'on voudra remettre en prod, notre base de données sera supprimée et on n'aura plus accès à toutes nos sessions utilisateurs.

34:17 Ce qu'on peut faire plutôt, c'est de décommenter le volume et de rajouter ce volume là. C'est-à-dire au lieu de créer un dossier cache dans notre directory, ici un dossier qu'on aurait appelé par exemple cache, on ne va pas faire ça. On va à la place bind un dossier session directement sur notre ordinateur, mais pour ce faire, nous allons d'abord devoir le créer. Donc pour le créer, voilà, on va clear le terminal et nous allons taper la commande m k dire tiret p pour dire que ça va être recursive et nous allons copier ce chemin. Donc slash dev slash volume slash NSGSR remix slash dev slash session.

34:52 Le deuxième slash dev, c'est au cas où vous voulez faire plusieurs environnements par exemple un dev, un staging et un prod. Mais regardez, si je tape cette commande, ça va me dire Operation not permitaged. Alors en fait, ça ne va pas être possible pour nous de sauvegarder les sessions sur notre environnement de développement dans ces dossiers-là. Par contre, on peut le faire dans le dossier cache nous allons créer comme ceci, donc on va créer un dossier qu'on va appeler cache qui va contenir le session redis. Par contre, en environnement de production sur un serveur Linux, il sera totalement possible pour nous de créer ce dossier-là.

35:26 Je pense que je n'ai pas réussi à le créer parce qu'on est sur Mac, mais ça sera totalement possible de le faire sur un serveur Linux. Maintenant, on va faire quelque chose. Si on retourne dans notre fichier main point t s, on peut voir ici qu'on a défini deux nouvelles variables d'environnement. D'abord une release url ici et la deuxième ça sera un session secrète comme celui-ci. Donc nous allons les déclarer dans notre fichier point invi.

35:47 D'abord notre redis url en local sera donc redis double point slash localhost soixante-trois soixante-dix-neuf. Et ça, c'est dans le cas où nous lançons notre application avec un NPM roledev. Je vais me re-déplacer dans le terminal, je vais donc fermer ce terminal et je vais rouvrir un terminal dans mon dossier projet. Maintenant, la deuxième variable d'environnement, ça sera un session secret et vous pouvez mettre ce que vous voulez ici. Généralement, ce que je fais, c'est que je cherche un générateur h deux cent cinquante-six par exemple, ici, chat deux cent cinquante-six online toon et je vais taper par exemple le nom du projet, par exemple coût de pouce tutoriel, et ici ça nous donne donc un hash de cette commande qu'on va donc copier et qu'on va rajouter en tant que session secret.

36:31 Maintenant ce release url va changer si on se connecte avec Docker. Parce que Docker va donc conteneuriser notre application et on n'a pas envie que notre base de données Redis soit accessible par l'extérieur. On a envie qu'elle soit accessible en interne et que notre mono repos slash dev ait accès au redis slash dev. Donc pour ce faire, nous allons devoir override cette url et nous allons le faire de cette manière au lieu que la valeur soit redis localast, comme ceci, qui sera donc égal à ça. À la place, la valeur sera égale à la place de localast, nous allons mettre le nom du service.

37:06 Dokor se chargera de remplacer ce nom-là par la bonne adresse IP. Il nous suffit donc de coller le nom du service ici, ce qui nous donne un URL de redis double point slash slash redis undersker serveur double point et le port reste le même. Maintenant, en production, on ne va pas ouvrir les ports de redis. Mais comme en ce moment, on est en mode développement, on peut les ouvrir pour déboguer et voir si nos données se sauvegardent bien. Donc ce qu'on a fait, c'est qu'on a ajouté un deuxième service Redis ici et il va maintenant falloir qu'on le télécharge et on téléchargera automatiquement cette image quand on lancera la commande docker compose tiret f de notre fichier.

37:43 On va donc la lancer tout de suite. Ici on voit que notre fichier s'appelle docker tiret compose point dev point m l, donc nous allons l'exécuter docker-compose-f docker-compose. Dev. Yml avec le mot clé up-bule. Assurez-vous bien sûr d'avoir l'application docker d'ouverte sur votre ordinateur, sinon ça ne va pas fonctionner.

38:04 En tout cas, pas si vous êtes sur un Mac et maintenant on appuie sur entrée comme ceci et on a une erreur au niveau du volume cache qui n'a pas été retrouvé et c'est normal. C'est parce qu'on a oublié de dire que c'est un chemin absolu comme celui-ci. Donc on va rajouter le point et le slash pour dire que ça va prendre ce dossier cache que nous venons de créer. On va réussir, on va retaper la commande et maintenant on va voir que ça poule l'image de Redis. Dans mon cas, j'avais déjà téléchargé l'image de Redis, donc ça ne va pas la retélécharger.

38:31 Par contre, ça va effectuer un build de l'application parce qu'on a modifié la base de code à cet endroit là. Notre projet a fini d'être build et il vient de se lancer et on peut voir qu'on n'a pour le moment aucun message d'erreur à part celui-ci ready connectd slash connectd. On a envie de vérifier plusieurs choses. Déjà, on va regarder sur Docker, on n'a aucune erreur, nos images Docker ne crachent pas et le serveur Redis est accessible sur le port soixante-trois soixante-dix-neuf. Ce qu'on peut faire maintenant, c'est qu'on va télécharger une application pour avoir une interface visuelle qui va nous permettre de vérifier quelles sont nos données.

39:06 Il existe peut-être des extensions v s code permettent de le faire. Personnellement, j'utilise une application qui s'appelle Redis Insights comme ceci, qu'on peut retrouver sur le site officiel Redis Insights the best release GEI. Il nous suffit donc de la télécharger pour notre système d'exploitation, personnellement mac os m un et ensuite de l'ouvrir et on peut voir qu'il a tout de suite détecté une base de données Redis à cette adresse-là. Maintenant, si on clique sur cette url, ici, on peut voir que ça va nous connecter à cette base de données. Et si on clique sur cette icône pour rafraîchir la page, on peut voir qu'on n'a aucun problème à nous connecter.

39:42 Ça veut dire qu'on est bien connecté à cette base de données. Par exemple, ce qu'on peut faire, c'est qu'on peut ajouter un champ ici. On va cliquer sur plus key comme ceci. On va rajouter un nom, par exemple Hello World et on va cliquer sur add key et on peut voir que cette donnée apparaît maintenant dans notre base de données. Si on rafraîchit, on retrouve la même donnée, on peut la supprimer comme ceci et ça va fonctionner.

40:02 Maintenant, ce qu'on va faire, c'est qu'on va recréer cette clé, le Worm. Maintenant, ce qu'on va faire, c'est qu'on va arrêter ce serveur release en cliquant sur stop ici. Maintenant, si on retourne sur le client release Insight, on rafraîchit la page, on a une erreur parce que le client n'arrive plus à se connecter, ce qui signifie qu'on était effectivement bien connecté tout à l'heure. Maintenant, on retombe ici, on va afficher le runner qu'on a désactivé et on va cliquer sur play pour le relancer. Si on retourne maintenant sur release Insight et qu'on actualise la page, voir qu'on a tout le site été reconnecté.

40:32 Donc, on arrive bien à accéder à ce docker. Maintenant qu'on a mis en place toute cette logique, on va de nouveau tenter de nous reconnecter avec l'application Postman. On retourne donc sur Postman et on va envoyer cette requête sur le port trois-mille comme ceci. Et là, on peut voir qu'on a un message d'erreur, une erreur cinq-cents avec un internal serveur erreur. Si on retourne dans VSCode, on peut voir qu'on a toujours nos log et la même erreur, faild to sérialize, user into session.

40:57 Mais si on retourne sur Redis Insight, on peut voir qu'il y a un nouveau champ qui a été sauvegardé dans la session. Si on clique dessus, on peut voir qu'on a donc un cookie avec un maxage, un x fire, le secure, le http only, le chemin et on a toutes les informations de notre cookie dans cette session-là. Il s'est donc passé quelque chose. Maintenant, on va essayer de déboguer cette erreur. Si on tape cette erreur sur Google, fail to serialis, user in to session, on peut voir qu'on a une réponse sur stack overflow, on va cliquer dessus et on va regarder la solution.

41:27 On regarde et ils nous disent qu'on n'a pas implémenté les méthodes passe porte point seria l'is user et passe porte point des seria lives user. On va tout de suite les implémenter et pour ce faire, nous allons créer un nouveau fichier qui s'appelle cookie tiret sérializer point t s. Et ça va être une classe qui s'appelle cookie sérializer et qui va faire un exten de la classe passeport serializer. Dedans, nous implémentons les deux méthodes des serialized uter et serialized uzer. Pour voir qu'on a des erreurs de type à ce niveau-là, mais on n'a pas besoin de s'en soucier, on va tout simplement faire un quick fixe et désactiver les erreurs type script s lint pour ce fichier avec cette instruction.

42:06 Effectivement, on ne va jamais toucher à ce fichier cookie sérializer. On en a besoin, donc on va l'importer dans le haut module ici. Va le rajouter comme provider à cet endroit-là. Maintenant, on va rafraîchir la page et nous allons rajouter un dernier paramètre dans le fichier main t s. À cet endroit-là, juste après le app use static asset, nous allons rajouter les deux instructions suivantes.

42:29 Nous allons rajouter l'instruction app point use passport point initialize et app point use passport point session. Et pour ce faire, nous allons importer la librairie passeport depuis passeport pour que ça ressemble à ça. C'est l'export par défaut de cette librairie et maintenant, on va actualiser cette page comme ceci. Comme nous avons modifié le code source, on va avoir besoin de kill notre conteneur docker et nous allons refaire un build avec la même commande. Ce qu'on peut faire avant d'attendre qu'elle build, c'est quand même de tester cette application, pas dans un docker, mais en local.

43:01 Pour ce faire, cependant, on a quand même besoin de faire tourner notre image Redis à cet endroit-là. Là, on peut voir qu'elle est liée à notre docker compose à cet endroit. Mais ce qu'on va faire, c'est qu'on va recréer un fichier docker compose comme celui-ci. Donc, on va dupliquer celui-ci et on va l'appeler docker compose point redis comme ceci et nous allons supprimer cette instruction, donc l'instruction de notre application en JavaScript pour ne laisser que JavaScript pour ne laisser que redis en standard on va l'appeler redis comme ceci et maintenant nous allons faire un docker compose tiret f donc du nouveau fichier que nous venons de créer docker compose point redis yamal hop on peut rajouter le tiret build mais il n'y aura aucun build à faire et on va rajouter le tiret d pour lancer redis en tâche de fond comme ceci. Maintenant, si on retourne sur notre client docker, on peut voir que la version standardone de Redis a été exécutée.

43:50 Comme on a ouvert les ports à cet endroit-là, Redis est disponible avec l'application Redis Insight. Si on rafraîchit la page, ici pour voir qu'on a toujours nos données. Maintenant que c'est le cas, on va se connecter et ça va utiliser cette adresse, donc à localhost soixante-trois soixante-dix-neuf. On va donc faire un NPM rundev comme ceci. On peut voir qu'on a une petite erreur dans le terminal à cet endroit-là, Classe constructeur Ready Store, Canon be Invoque, without new.

44:13 Mais dans notre cas, ce n'est pas du tout ce qu'on fait. Ici, on peut voir qu'on fait un new Ready Store pour nous connecter à notre store. Ensuite, nous avons cette erreur ready is al ready connecting slash connected qui est un petit peu bizarre, mais l'application arrive quand même à se lancer. On retourne maintenant sur Postman et on va tester une dernière connexion. On appuie sur Send et cette fois, on a eu un deux-cent-un created.

44:34 Donc on a eu aucun message d'erreur, ce qui veut dire qu'on est bien connecté à notre application. Maintenant si on retourne sur Redis Insight, qu'on actualise, on peut voir qu'on a toujours la même session, mais cette fois, on a les propriétés de notre utilisateur qu'on avait sauvegardées. Regardez, on retourne ici dans le fichier local stratégie, au lieu de renvoyer une ID de un, on peut par exemple envoyer les informations comme l'e-mail et le password, ce qui est bien sûr pas recommandé, mais on va le faire pour la science. Maintenant, on retourne dans l'application, on va supprimer cette session, on supprime également la deuxième session Maintenant si on retourne sur pass man, on va cliquer sur scène comme ceci, on a de nouveau eu une deux cent un, donc un statut de succès et on retourne maintenant sur Redis Insight, on rafraîchit la page et on retrouve notre session utilisateur avec les bonnes informations. On a donc notre ID, notre email et le password dans notre session utilisateur.

45:26 Et c'est super cool parce qu'à tout moment, on a maintenant un contrôle sur les sessions qui sont actives pour chacun de nos utilisateurs. Ça veut dire qu'on pourra les déconnecter à distance cliquant par exemple sur cette poubelle, ce qui va forcer une reconnexion de leur part. Maintenant que c'est fait, on va rajouter un petit morceau de logique pour pouvoir nous connecter à notre application depuis le front-end. Donc on va écrire pour le moment dur notre tableau d'utilisateur. On va donc avoir un utilisateur qui va donc s'appeler Virgile avec comme mot de passe un deux trois et comme adresse email virgile arobase alco max point f r.

45:60 Maintenant, nous allons regarder si l'utilisateur qui tente de se connecter existe bien. Pour ce faire, on va vérifier si l'utilisateur existe en faisant un somme de notre tableau utilisateur avec un arrêt pour somme et en faisant une comparaison sur l'email que nous n'avons pas créé. On va ajouter la clé tout de suite. Si l'e-mail est égal à l'e-mail qui était renvoyé depuis le front-end, on va donc faire un to low workase pour être sûr et que le mot de passe est égal mot de passe sauvegardé en base de données qui encore une fois pas du tout sécurisé. Ne vous inquiétez pas, on ne va pas sauvegarder les mots de passe en dehors, mais pour le moment, pour tester que ça fonctionne bien, on va le faire.

46:34 Si l'utilisateur n'existe pas, alors on va, trop une erreur de ce type, les identifiants sont invalides comme ceci. On va donc importer cette erreur depuis net g s slash commun. Par contre, si les identifiants existent, ça veut dire qu'on a trouvé cet utilisateur. Donc, on va faire un find dessus, find User est égal à users point find et on va repasser les mêmes arguments. On va faire une comparaison sur l'email et le mot de passe comme ceci et on va tout simplement envoyer le sound user comme ceci, ce qui nous donne donc ce code maintenant pour se connecter, on va taper donc cet email et ce mot de passe.

47:11 On va essayer dans Postman, mais souvenez-vous, Postman ne fonctionne pas et on a besoin de lancer la requête sur un navigateur. C'est pourquoi dans notre fichier local postgound, ici, on avait écrit en dur nos données. Maintenant, ce qu'on peut faire, c'est qu'on va ajouter par exemple cet email et on va faire une faute à cet endroit-là. Si on fait une tentative de connexion, on peut voir qu'on a bien un message d'erreur les identifiants sont invalides. C'est normal, notre email est invalide.

47:36 Par contre, si on retire ce message d'erreur, qu'on essaie de se connecter comme ceci, on peut voir qu'on a toujours ce message d'erreur qui est pourtant bizarre parce que nos données sont bien conformes. On va faire un console log de notre tableau d'utilisateurs et donc de notre email et du mot de passe comme à cet endroit-là. Maintenant, on va réexécuter la requête comme ceci et là, on peut voir que les données sont quasiment pareilles. On a donc un email, un email. Le mot de passe, il est exactement pareil.

48:01 Je ne comprends pas d'où le problème vient. Donc ce qu'on va faire plutôt, c'est qu'on va changer un petit peu cette logique. Ici, on fait un sum et un fail, mais on pourrait encore simplifier cette logique de cette manière. Par exemple, thang email et dans ce cas là, on va seulement vérifier que les deux emails sont de la même valeur. Si on n'a pas trouvé d'utilisateur avec cet email, donc c'est trop une erreur.

48:23 On va dire le compte n'existe pas. Ce qu'on est en train de faire, c'est évidemment une feuille de sécurité parce qu'on est en train de dire que cet email n'existe pas. Mais bien sûr, on va changer tout ça avant de mettre en prod. Maintenant, si on dépasse cette condition, ça veut dire qu'on a trouvé un email et on va maintenant comparer les mots de passe. Is password de Same.

48:40 Pour ce faire, on va donc comparer l'email qu'on a trouvé la base de données avec le mot de passe qui vient de nous être envoyé. Et on va copier cette erreur, sauf que ça va être pour la condition is password de saim. Si c'est faux, alors on va mettre le mot de passe est invalide comme ceci. Sinon, si toutes ces sécurités ont été passées, ça veut dire que l'email a tapé un bon mot de passe et un bon email. Donc, on va le renvoyer comme ceci.

49:04 Maintenant, on va refaire une tentative. On retourne sur passman, on va envoyer notre requête et cette fois, on voit qu'il n'y a plus aucune erreur, qui est plutôt cool. On a donc été identifié en tant que Virgile arobase barcov point alcomax, mais si on retourne à tout moment de notre local Osgard à cet endroit et qu'on modifie notre mot de passe comme ceci et qu'on retourne maintenant sur Pastman et qu'on clique sur Send, on peut voir qu'on a l'erreur, le mot de passe est invalide. Si on change maintenant l'adresse email, on la remplace comme ceci et qu'on retourne sur Passman, on peut voir que l'erreur, c'est le compte n'existe pas. Notre logique fonctionne très bien.

49:36 On va remettre les valeurs initiales qui fonctionnent. On va retourner sur Redis Insight et on peut voir que ça a toujours créé notre session utilisateur dans la request. Donc, on a la propriété user et cette propriété, elle est maintenant disponible dans nos contrôleurs ici. C'est le request. User.

49:55 Cette propriété contient donc notre ID, notre email et le mot de passe en clair. Maintenant que c'est fait, nous allons implémenter cette logique dans le front-end. On ouvre donc notre dossier front-end, puis notre dossier app et enfin notre dossier route. Et à l'intérieur du dossier public, ici, nous allons créer une nouvelle route qu'on va appeler login point TFX. Pour le moment, on ne va pas encore créer l'inscription, on va seulement nous occuper de la connexion.

50:19 Pour ce faire, on va donc exporter une fonction par défaut comme ceci. On va appeler login et ça va renvoyer un h1, par exemple. On va écrire connexion et nous allons ajouter un formulaire. Ça sera donc un post et on va poster sur la route slash os slash login qui est la route de notre contrôleur, os contrôleur. Ici, on aura donc deux champs, on aura un input de type email qui aura comme nom email comme ceci, et on aura un deuxième input de type password qui aura comme nom password comme ceci.

50:50 On va enfin ajouter notre bouton depuis et on va l'appeler se connecter. Le type sera Submit parce qu'on a envie de soumettre ce formulaire. On a bien sûr des erreurs au niveau de la résolution de ce module, mais ce n'est pas grave. Si maintenant on se rend sur Google localos trois mille slash login, on peut voir qu'on a notre page de connexion avec nos deux inputs ici. Évidemment, c'est plutôt moche.

51:13 Donc, on va retourner sur et on va chercher des inputs inputs comme ceci et nous allons ajouter le composant inputs avec NPM. Maintenant dans notre terminal, on va donc faire un cd de frontend et nous allons installer ce composant là. On peut maintenant importer l'input depuis child component UI input comme ceci. Nous allons remplacer nos deux inputs comme ceci et nous allons ajouter un petit peu de style du flex flex call avec un gap et le bouton sera aligné à droite et nous allons rajouter un div pour englober cet élément et nous allons mettre une largeur maximum de 6 cents pixels et nous allons centrer ce contenu comme ceci. Maintenant, on peut relancer notre serveur, donc on n'oublie pas de faire un cd double point parce qu'on est dans le dossier front-end et nous allons refaire un NPR al dev comme ceci.

51:59 Et si on retourne sur notre application, maintenant, on a un formulaire un peu plus stylé. Alors bien sûr, il faudrait qu'on rajoute des labels, mais pour le moment, ça va nous convenir. On a juste envie de vérifier que ça fonctionne bien. Pour vérifier que ça fonctionne bien, on doit d'abord retourner dans notre local Osgard ici et nous allons supprimer ça pour ne pas que ça aille modifier les valeurs que notre application va envoyer. On commande donc ces lignes qui n'étaient pas utiles, mais qui nous permettaient de tester l'application avec passman.

52:27 Et maintenant, on retourne dans notre formulaire et nous allons taper donc les bonnes coordonnées, donc la bonne adresse email et le bon mot de passe un, deux, trois. On clique sur se connecter et on a une erreur de ce type. Vous n'avez pas le droit d'accéder à cette page. Intéressant, cette erreur, un autosised exception parce qu'on n'a pas trouvé d'utilisateur dans la requête. Ici, si on regarde les logs, l'utilisateur est à false.

52:52 On a cette erreur parce qu'on a oublié quelque chose de très important. En fait, ici, on n'arrive pas à percer les éléments sous forme de Jason. Et c'est pour la simple et bonne raison que dans le main point t s, ici nous avons désactivé body parser. C'est bien embêtant parce qu'on a quand même besoin d'activer body parser pour cette route au Slogin. Donc ce qu'on peut faire, c'est qu'on peut à la place installer body parser.

53:15 Pour ce faire, on va ouvrir un deuxième terminal, on va faire un CD dans le backend et nous allons lancer la commande NPM install body parser. On va quand même regarder comment la librairie s'appelle sur NPMGS point com body tiret par soeur je crois, c'est bien elle, elle a été téléchargée trente-trois millions de fois, on va l'installer tout de suite body tiret par soeur comme ceci. Nous allons également installer ces types, on peut voir sur NPM qu'elle propose des types donc arobase tips slash body par sort. On va donc les installer en tant que dev depandomsey, comme ceci. Maintenant, on peut qu'il le terminal et ici, on va rajouter un middleware.

53:49 En plus, ça va être un app point use et nous allons spécifier que sur la route slash hausse slash login que nous avons déclaré dans notre contrôleur, nous voulons activer URL encoded. URL encoded, c'est une méthode qu'on importe depuis poli par soeur. Et en fait, ça va tout simplement parser les données dans notre requête. Maintenant, on actualise ce qui va relancer notre application Nest JS et on va retourner sur Chrome pour faire une nouvelle tentative dans notre formulaire. On va retaper le mot de passe un deux trois, on va cliquer sur se connecter et cette fois, on n'a eu aucune erreur.

54:22 Ça ne nous a rien renvoyé. Si on retourne sur Redis Insights, on peut voir qu'on est connecté cette fois avec une deuxième session parce qu'on a changé de navigateur. La première session elle avait été ouverte avec Postman, cette deuxième session elle est ouverte avec notre navigateur Chrome. On est donc connecté avec succès. Ça marche très bien.

54:40 Donc on va retourner sur notre application, ici sur la page d'accueil et on a envie de rajouter un statut spécial pour les utilisateurs qui sont connectés. Donc on va se rendre dans notre index ici, on va retirer tous les boutons et nous allons dans le fichier root déclarer une nouvelle méthode. On va exporter cette méthode et on va l'appeler get optionnelle user comme ceci. Cette méthode ne sera pas asynchrone et elle va prendre en paramètre notre contexte. Le contexte prend le type apploader, app load contexte, on importe depuis remix run slash mode.

55:10 Pour rappel, le contexte nous l'avons déclaré ici, on a donc le remix service et le toto. Et ce qu'on a envie de faire, on va supprimer d'ailleurs le toto parce qu'on en a plus besoin, c'est de retourner dans le fichier remix contrôleur, donc dans Nest JS et ici à la place de toto, nous allons renvoyer l'utilisateur avec un request point user comme ceci. Et ce qu'on veut faire pour le moment, c'est juste console loguer l'utilisateur dans notre application remix. Maintenant, on retourne dans le root et on va rajouter donc la propriété user. On va mettre que c'est un comme ceci et nous allons maintenant la renvoyer en faisant return contexte point user comme ceci.

55:48 Cette méthode, on va maintenant cette méthode, c'est une méthode côté serveur. Je l'ai déclaré dans le root, mais en fait, il serait plus judicieux de créer un nouveau dossier qu'on appellerait serveur à cet endroit-là. Et dans ce dossier, on créerait un nouveau fichier qu'on appellerait par exemple hausse point serveur point t s. C'est dans ce fichier là qu'on importerait cette méthode là. On va le faire tout de suite dans notre fichier os serveur.

56:11 On va donc importer le type et on va renvoyer cette méthode. Cette méthode renvoie donc un nom et on va l'appeler maintenant dans notre fichier root pour pouvoir connaître notre état de connexion sur toutes nos pages. Pour ce faire, on va donc exporter par défaut une méthode l'odeur. Ici, donc on va exporter l'odeur qui est une méthode asynchrone qui contient donc notre request et notre contexte. On aura besoin pour le passer en paramètre et nous allons appeler maintenant notre méthode get optionnel user qui prend en paramètre le contexte et qui renvoie à un utilisateur optionnel.

56:43 On va donc faire un const user est égal à get optionnel user et on va le renvoyer côté client sous forme de JSON comme ceci. Maintenant que c'est fait, on est actuellement dans le fichier root et ce qu'on peut faire, c'est qu'on va créer maintenant un hook qu'on va appeler use optionnel user. Et ce hook, il va récupérer la donnée qui est renvoyée depuis le serveur et ça va nous permettre d'utiliser ce hook sur toutes nos pages. On récupère donc d'abord un objet data depuis use loader data qui est le hook de React CoTiclient qui nous permet de récupérer les données que notre serveur remix nous envoie et nous allons lui donner comme type générique le type que nous renvoie la méthode qui s'appelle l'odeur. On peut voir donc que dans data, on possède une propriété user qui est annove.

57:24 Mais ce n'est pas sûr que le Loader renvoie une donnée. Donc ce qu'on va faire, c'est if not data, alors on va se trouver une erreur root loader, deanut return, un effet, ce qui ne va bien sûr jamais arriver. Et maintenant, comme le hook s'appelle use optionnelle user, on va renvoyer la propriété data point user qui est optionnel. Maintenant, ce hook là, useloader data va récupérer les données depuis la route actuelle. Ça veut dire que si on appelle ce hook sur la route login, on avait créé ici, ça ne va pas fonctionner parce que la route login ne renvoie pas la donnée de l'utilisateur.

57:58 Donc au lieu d'utiliser le hook use loader data, on va plutôt utiliser le hook use root loader data. Et ce hook use root loader data va nous permettre de spécifier le nom, donc l'ID de la route en question. L'ID de notre route actuelle, c'est le fichier root, donc r deux o t, comme ceci. Maintenant, on va exporter ce hook use optionnelle data et on va nous rendre sur la page login comme ceci et nous allons l'utiliser. On va donc dire que user est égal à use optionnelle user, on importe depuis root, on va voir que les types sont automatiquement inférés comme ceci et nous allons afficher json stringify pour voir ce qu'il y a dans cet objet.

58:37 Peut-être qu'il est nul, peut-être qu'il n'est pas nul. Maintenant, on rafraîchit la page et on va retourner sur notre navigateur sur la page login. Et là, on peut voir qu'on a donc bien les informations qui sont présentes dans notre session. Ici, sur Redis Insight, on a ces mêmes informations-là. Si on supprime la première session qui avait été créée depuis Postman et qu'on actualise de nouveau la page, on peut voir qu'on n'a plus des informations.

58:59 Ça veut dire qu'on a été déconnecté. Je je me suis trompé, j'ai supprimé la mauvaise session. On va donc supprimer la deuxième session, cette fois, on n'est plus connecté, comme on n'est plus connecté, on peut de nouveau se connecter. Si maintenant on se connecte avec le mot de passe un deux trois, ici, ça nous redirige sur la partie hausse slash login, actuellement on ne fait pas de redirection dans notre application, on peut la faire tout de suite dans le haut contrôleur. Ce qu'on peut faire à cet endroit-là pour le moment, c'est d'importer le décorateur qui s'appelle redirect et nous allons faire une redirection ici sur la page d'accueil pour le moment.

59:31 Maintenant, pour refaire un essai, si on se connecte comme ceci, on est redirigé sur la page d'accueil. Ce qu'on a envie de faire maintenant, c'est d'afficher les informations de notre utilisateur. On va les afficher dans la navigation, dans notre fichier navbar ici. Dans ce fichier navbar, on va donc appeler le hook use upchournal usor vu que la navbar est définie dans le fichier root et que c'est le fichier root qui renvoie la donnée de notre utilisateur. Totalement possible de le faire.

59:57 Et nous allons rajouter une condition, si l'utilisateur existe, alors on va par exemple afficher son prénom, sinon on ne va rien afficher. Maintenant, bien sûr, on a envie de connaître les types de notre utilisateur. Ce qu'on peut faire, c'est qu'on peut retourner dans notre fichier os serveur. Nous avions déclaré ici dans remix et nous allons importer Zod depuis la librairie Zod. On peut voir qu'on n'a pas encore téléchargé cette librairie.

60:20 Donc, on va le faire tout de suite. On se rend dans le fichier frontend et on va installer zod, qui est une librairie qui va nous permettre de valider les données. Maintenant que c'est fait, ça, on importe Zod et on va écrire le schéma de notre utilisateur. Donc authenticated Uther Schema est égal à Zod, c'est un objet et ça va contenir une ID qui est un string, un email qui est un string et un name qui est un string. Bien sûr, le mot de passe, on n'a pas envie de le récupérer.

60:47 Si on retourne sur Redis, ici, on peut voir qu'on a bien un name, une ID qui n'a pas l'air d'être un string. Je pense que c'est un number et on a bien notre email. On va donc modifier ce schéma-là. On va dire que c'est un number, mais pour la méthode get option user, nous allons modifier un petit peu ce schéma. On va donc renvoyer cette donnée par c, mais comme l'utilisateur peut être optionnel avant d'effectuer le par c, nous allons rajouter le mot clé obchampal et nulable pour dire que ça peut tout bonnement être nul.

61:13 Maintenant si on passe la souris sur get obchampal user, on peut voir qu'on a soit un tableau d'utilisateur, soit nul, soit une define. Ce qui est cool, c'est que maintenant, on peut tout de suite créer une deuxième méthode pour forcer l'utilisateur. Pour ce faire, on va appeler cette méthode require user. Cette méthode-là, on va l'appeler sur les routes où on est obligé d'être identifié pour y accéder. Et au lieu de refaire un parse, nous allons tout simplement récupérer l'utilisateur depuis cette méthode get uption new user.

61:38 Il se trouve plus haut comme ceci. Et si l'utilisateur n'existe pas, on va tout simplement throw pour le moment une redirection sur la route login par exemple. Et on apporte la redirection depuis remix râle slash note. Sinon, si l'utilisateur n'a pas été straw, ça veut dire qu'il est bien défini, donc on peut le renvoyer comme ceci. Maintenant qu'on a utilisé Zodd pour passer le schéma, si on retourne sur notre not bar ici, on connaît dans notre hook les types de cet utilisateur.

62:04 Donc, on peut très simplement afficher le nom de notre utilisateur sur la nappe barre. Si maintenant on retourne sur Chrome, on peut voir ici que je suis connecté en tant que Virgile. Maintenant, je suis connecté et j'aurais envie de me déconnecter. Pour ce faire, on va ajouter une nouvelle méthode à notre application Back and. Ici, on va se rendre dans notre fichier hausse point controller et nous allons ajouter une deuxième méthode.

62:26 Ça sera donc un post sur la route logout comme ceci et on va récupérer des propriétés request, response qu'on importe depuis Nest JS et la méthode next qu'on importe aussi depuis Nest JS. On va également importer le type et on va regarder ce que cette méthode nous permet de faire. Effectivement, notre request express pour request possède une méthode log-out ici. Et ce qu'elle va faire, c'est qu'elle va tout simplement détruire la session active et effectuer une redirection sur la page d'accueil. On peut voir que j'avais importé le mauvais type à ce niveau là parce que je n'ai pas importé le type de response.

63:00 On n'avait aucune erreur. Mais si maintenant j'active l'autocompletion et que j'importe le type depuis express, on peut voir que ces erreurs ne sont plus en rouge. Donc, on peut maintenant retourner sur notre navbar ici et on va afficher conditionnellement une icône à la fin. Si l'utilisateur est connecté, nous allons rajouter un bouton qui va permettre de se déconnecter comme ceci. Pour ce faire, on va donc ajouter un formulaire et un bouton de type Summit et notre formulaire aura comme méthode post et comme action la méthode slash logout qui est donc la nouvelle route que nous venons de déclarer ici.

63:35 Pour être fidèle à notre hommage, on va l'appeler hausse slash logout. On va ici rajouter le slash hausse slash logout et il ne faut pas oublier dans le main de quand même spécifier cette méthode pour utiliser Audi Percer. Parce que pour le moment, on ne va rien envoyer comme données, mais si à l'avenir, on a envie par exemple d'envoyer une clé de redirection, c'est-à-dire sur quelle page renvoyer l'utilisateur après la déconnexion, on pourra le faire, mais seulement si on active body parser sur la route slash os slash logout comme ceci. Maintenant on va retourner sur notre application. Ici on peut voir on est connecté, Le bouton se déconnecter apparaît bien et sur Redis Insight, on est connecté.

64:15 Si maintenant on clique sur le bouton se déconnecter, on peut voir qu'on a maintenant été déconnecté on a été redirigé sur la page d'accueil. Si on retourne sur Redis Insights et qu'on actualise la page, on ne retrouve plus notre session. Elle a donc bien été supprimée. Maintenant, si on retourne sur Google et qu'on cherche à se connecter, pour ce faire, on avait rajouté un lien sur notre Navarre ici, c'est l'icône d'utilisateur, donc on va cliquer dessus, qui nous redirige sur la page de connexion. On va se reconnecter.

64:42 On est donc redirigé sur la page d'accueil et maintenant, au lieu de se déconnecter directement sur l'application, on va voir ce qui se passe si un admin, par exemple, décide de supprimer la session. On retourne donc sur Redis Insight, on va actualiser la page ici et on peut voir qu'on a de nouveau notre session. Si on clique maintenant sur l'icône de poubelle ici et qu'on supprime notre session et qu'on retourne maintenant sur Remix, on actualise la page et là on peut voir qu'on n'est plus connecté. On n'a plus les icônes sur notre navbar. La connexion fonctionne très bien et la déconnexion fonctionne très bien.

65:14 Pour le moment, elle fonctionne par mot de passe et nous n'avons pas encore configuré notre base de données. On va maintenant configurer notre base de données. Pour ce faire, on va aller sur le site Néon point tech qui nous permet gratuitement de créer une base de données serverless en utilisant PostgreS. On peut voir ici dans Price in qu'il y a un tiers gratuit très généreux avec du stockage et notre base de données disponible h vingt-quatre. On va donc cliquer sur login.

65:38 Dans mon cas, je me suis déjà connecté avec le compte Gmail ici et nous allons appeler notre projet coût de pouce et comme nom, on pourra l'appeler coût de pouce comme ceci. Comme région, nous allons sélectionner Europe pour être plus proche de nos serveurs français. Maintenant, on va créer ce projet et nous allons copier cette url de connexion, mais nous allons plutôt cliquer sur connexion string ici et nous allons sélectionner Prisma. Effectivement, on a aussi besoin de sélectionner le provider à cet endroit. Donc, on va tout de suite le faire.

66:09 On ouvre donc notre terminal et on va qu'il le projet et nous allons aller dans le dossier back and et nous allons installer librairie Prisma en tant que dev depannency. On va ensuite faire un npx prisma init comme ceci, ce qui nous a donc créé un nouveau fichier dans le backend. On a donc un dossier qui s'appelle Prisma avec notre schéma ici et on peut voir que par défaut, ça a sélectionné notre base de données comme étant une PostgreS. Maintenant, on va devoir installer le client Prima. On va donc faire un npm install de arobase prisma slash pient, appuyez sur Entrée comme ceci pour l'installer dans notre backend.

66:49 Et nous allons maintenant ouvrir notre variable d'environnement à cet endroit-là, nous allons rajouter une clé qu'on va appeler database underscore url et ça prendra comme valeur cette valeur-là dans notre point en vie ici on va donc copier cette ligne de code à ce niveau là. On va la coller comme ceci et on a maintenant accès à notre base de données coup de pouce avec ce mot de passe et cette adresse IP. Maintenant, on va cliquer sur I don't that later et nous allons créer notre schéma Prima. On souhaite donc pour le moment avoir un modèle utilisateur. On aura donc une ID sous forme de string.

67:23 Copilot a très bien compris ce qu'on voulait faire et nous avons un email, un name et un password. C'est très bien. Bien sûr, le mot de passe sera haché, l'email, il sera unique, c'est exactement ce qu'on veut et nous allons aussi créer un deuxième champ qu'on va appeler session comme ceci. Il y aura pareil une ID qui utilise un QID comme ceci. Il sera lié à notre utilisateur avec ce schéma-là.

67:45 Nous allons rajouter également des informations en plus. Par exemple, l'adresse IP, le user agent va nous permettre de déterminer quel navigateur a été utilisé ou quel device et un token de session à usage unique. Maintenant on va rajouter cette clé cession au pluriel ici en faisant référence à notre modèle comme ceci et c'est tout pour les modèles pour le moment. Donc on va faire un NPX prisma migrate dev tiret tiret name ine prisma comme ceci. Effectivement, on a un petit message d'erreur ici, petit problème à ce niveau-là qui nous dit que John Doe n'arrive pas à se connecter à la base de données my d b point public et c'est tout simplement parce que Prisma a créé un fichier point en v dans notre backend ici avec une adresse bidon de base de données.

68:29 On peut donc supprimer ce fichier .env ici parce que nous allons utiliser le .env de la racine de notre application. Mais pour ce faire, on a donc besoin de le copier quand même dans le fichier backend parce qu'on va générer les migrations, on le fera dans le fichier backend. Donc pour ce faire, on remonte d'un cran dans les dossiers et nous allons faire un CP dans le fichier point INV et nous allons le copier dans le dossier backend comme ceci. Maintenant, on peut voir que ça a recréé notre fichier de variable d'environnement. Si on retourne une nouvelle fois dans backend et qu'on recopie la commande pour initier Prima comme ceci, on peut voir que ça a bien créé notre fichier de migration.

69:07 Si on retourne sur M&M. Tech ici et qu'on clique sur Aballs, on peut voir qu'on a bien trois tables. On a notre table user et on a notre table session ont bien toutes les deux été instanciées. Maintenant, on va retourner dans notre application Nestk. Js ici dans le back and et dans le dossier SRC et nous allons créer un fichier qu'on va appeler Prima qui va contenir un service qu'on va appeler Prima point service point t s par défaut.

69:31 On va donc exporter une classe qu'on va appeler Prima service et qui va faire un extends depuis le prisma client. On importe depuis arobase prisma slash client comme ceci. Et bien sûr, on veut l'injecter avec l'injection de dépendance, donc on va rajouter le décorateur injectable qu'on importe depuis neste .C'est tout ce qu'il nous reste à faire pour pouvoir utiliser Prima dans notre application. Maintenant, si on retourne dans le module hausse en module, cet endroit là, on va importer comme provider le prisma service que nous venons de créer et maintenant dans notre fichier local stratégie ici au lieu de déclarer un tableau en dur d'utilisateurs, nous allons plutôt passer dans le constructeur ici notre private reenonly prisma, qui va être en fait notre prisma service. Cette fois, on va l'importer depuis le fichier que nous venons de créer tout à l'heure et nous allons regarder un utilisateur existe dans Prima.

70:26 On va donc faire un nawate de dix point Prima, qui est notre service que nous venons de créer point user et on va faire un find unique sur le champ email. On va rajouter un where email est égal à l'email, donc cet email-là qu'on récupère en paramètre. On peut maintenant supprimer cette instruction. On va remplacer cette variable, donc si on n'a pas trouvé d'utilisateur avec cet email, le compte n'existe pas. Pour être reçu, on va rajouter un to le workase pour éviter que les emails en majuscules se sauvegardent dans notre base de données.

70:57 Maintenant, est-ce que le mot de passe est le même On va faire une comparaison avec l'utilisateur comme ceci et si le mot de passe n'est pas le même, on va se trouver une erreur. Sinon, on va renvoyer notre utilisateur qui possède maintenant un peu plus de champs. Mais pour être synchro avec ce qu'on renvoie côté client, on va seulement sélectionner les champs ID, email, name et password comme ceci. Maintenant, on peut supprimer ces variables là et on peut de nouveau ouvrir notre terminal et faire un NPX prisma studio comme ceci. Et dans Studio, nous allons créer notre premier compte utilisateur.

71:29 Ça prendra donc comme email virgile arobase algo max point f r comme nom virgile et comme mot de passe un deux trois. On sauvegarde le changement et maintenant on va Kill Prima Studio, on va remonter d'un cran dans les dossiers et nous allons relancer le projet avec un NPM rundev. Maintenant, on peut retourner sur notre application ici, on rafraîchit la page et on peut voir qu'on n'est plus connecté. Bien sûr, si on se connecte avec notre compte virgile arobase algo max point f r et qu'on rentre le mot de passe un deux trois et qu'on se connecte, on peut voir qu'on a eu une grosse erreur de par signe. Pourquoi à votre avis Ici, si on regarde le terminal, on peut voir qu'il s'attendait à recevoir un number et il a reçu un string.

72:08 Effectivement, on a connecté l'utilisateur sauf que au niveau du par signe d'exode, on dit que l'ID est un number alors qu'en Set, c'est un string ici. Maintenant, on va modifier ce schéma Zod comme ceci, ça ne devrait plus poser problème. Si on retourne sur notre application, la page d'accueil, on peut voir qu'on est toujours connecté en tant que Virgile. Pour en avoir le coeur net, on va retourner dans notre application et on va faire un cd backend et nous allons faire un NPX prisma studio et on va modifier mon nom, on va m'appeler Carlos comme ceci et si on retourne dans notre application, on rafraîchit la page, on peut voir que ça ne modifie pas mon prénom. Alors pourquoi ça ne le modifie pas Si on retourne sur Redis Insight, c'est parce que le prénom, il a été sauvegardé dans notre base de données Redis.

72:51 Donc ce qu'on peut faire, c'est on retourne dans notre application Nest. Js dans le fichier remix Controller et Et à cet endroit-là, au lieu de renvoyer un request en user, nous allons dans notre remix service ici déclarer une nouvelle méthode qui va tout simplement récupérer les informations de notre utilisateur. On va donc appeler la méthode get user comme ceci et ça va prendre en paramètre une ID qui est sous forme de string qu'on va plutôt appeler user ID et nous allons ensuite rajouter un constructeur qui va lui aussi importer notre private in Only Prisma, qui est donc notre service Prisma et nous allons renvoyer un await de dix point prisma point user find unique sur son user ID qui est donc son ID. C'est une méthode donc asynchrone et ça ne va pas renvoyer un string. On va laisser le type générique se charger de ce qu'elle renvoie.

73:40 Bien sûr, on va quand même sélectionner les quelques propriétés comme l'ID, le name et les mails. On ne va donc pas renvoyer le mot de passe et à ce niveau là, dans le root point TFX, ici dans la méthode get optionnel user, on va rajouter un morceau de logique. On va donc récupérer l'utilisateur et si l'utilisateur existe, on va donc renvoyer la méthode que nous venons de créer dans notre contexte. Donc on va faire un contexte en remix service point get user sur son ID, user ID est égal à user point ID, ce qui veut dire que ça va donc envoyer les options fraîches depuis Prisma, sinon on va renvoyer nul comme ceci. Bien sûr cette méthode est sous forme de promesses donc on ne va pas oublier de la weight et comme nous la weightons maintenant on va marquer ces deux méthodes comme étant asynchrones comme ceci.

74:24 Donc, on va faire un await get uptional user comme ceci et on peut voir qu'on renvoie maintenant soit un utilisateur, soit nul. Si on retourne dans notre application, on peut voir ici qu'on a une erreur dans le fichier app module. Pourquoi Parce que dans le fichier app module, on importe le service remix, mais on n'importe pas le service Prima dont le service remix dépend. Donc on va importer tout de suite le service Prima. On va maintenant retourner sur notre navigateur Et si on actualise la page, on peut voir qu'on n'a plus notre nom.

74:53 Ici, parce que dans le fichier root, ici, on n'a pas await cette promesse. Effectivement, devenu une promesse. Donc, on va devoir lawait et maintenant, on peut voir que le nom a bien été mis à jour. Si on renomme encore et qu'on appelle Frédéric comme ceci, on peut voir que le nom se met à jour et on n'a pas besoin de mettre ces informations à jour dans la session. De toute manière, c'était un exemple de sauvegarder informations comme le nom, le mot de passe et l'email.

75:17 En vrai, on n'aura jamais besoin de le faire. Ce qui nous intéressait ici, c'est plutôt l'ID de l'utilisateur.