Authentification (partie 2) par token avec Docker, Redis, Express Session

00:00 Dans la vidéo précédente, on avait implémenté ensemble une partie de l'authentification de notre application. Comme c'est une grosse partie, voici la deuxième partie. Aujourd'hui, on va continuer et on va implémenter la fonctionnalité d'inscription et on va également améliorer l'expérience utilisateur de nos formulaires en utilisant une super librairie que j'ai hâte de vous faire découvrir. Mais attention, cette vidéo va être différente des autres la simple et bonne raison qu'elle avait déjà été enregistrée. Sauf que l'enregistrement est complètement inutilisable.

00:30 Alors, au lieu d'annuler des changements, de développer à vos côtés, je vais plutôt vous présenter mon avancée dans le développement de cette magnifique application. Pour les personnes qui me découvrent avec cette vidéo, vous pouvez accéder à sur GitHub et vous pouvez voir qu'on est à la cinquième partie d'une série de formation pour implémenter une stack remix et Nast JS. Dans la description de repository, vous trouverez les liens vers les parties précédentes. Ici par exemple, si vous cliquez sur la vidéo, sur la partie un dans la description, vous trouverez la playlist complète avec les vidéos précédentes de cette série. Dans notre cas, nous allons utiliser la branche qui s'appelle zéro quatre tiret authentification ici.

01:10 C'est-à-dire que nous allons cloner ce repository en utilisant git dans le terminal comme ceci avec la commande git clone et le lien vers le repository et on va lui attribuer un nom par exemple ma super stack ce qui va nous permettre de continuer notre développement. Ensuite on va faire un cd sur ma super stack et un NPM install comme ceci et ce qu'on a envie de faire maintenant, c'est de faire un git check out sur cette branche-là, donc la branche zéro quatre tiret authentification comme ceci avant de pouvoir lancer le projet. J'avais déjà le projet d'installer en local, alors je l'ai ouvert avec VSCAD et Il y a également un dernier prérequis pour avancer sur ce chapitre, c'est d'utiliser redis. On peut voir dans les fichiers qu'on a un docker compose point redis ici et ce fichier va nous permettre d'exécuter redis avec Docker. On utilise donc le client docker desktop que vous pouvez télécharger et on exécute ensuite une commande dans le terminal pour lancer un serveur d'Oredis sur le port soixante-trois, soixante-dix-neuf.

02:07 Je vous rappelle donc la commande pour lancer ce fichier. Il suffit de faire un docker compose tiret f et le nom de ces fichiers à la racine du projet. C'est cette commande qui s'affiche dans le terminal. Du coup, c'est un docker compose tiret nom du fichier tiret tiret build et tiret d pour l'exécuter en tâche de fond. Par exemple, ce qu'on peut faire, c'est qu'on peut stopper cette image complètement et nous allons maintenant lancer la commande, ce qui va lancer donc notre image release standardone et si on retourne sur docker, on peut voir que ça crée un autre conteneur qui s'appelle Nest Gs remix mono repos avec le redis standardone qui est en train d'être exécuté.

02:44 Dans la vidéo précédente, on avait également téléchargé l'application Redis Insight, ici qui nous permet de voir toutes les données qui ont été sauvegardées dans notre base de données. Quand vous lancez l'application pour la première fois, vous arrivez sur cet écran et ici, on peut voir que l'application a déjà détecté qu'on exécutait une instance d'Uuridis. Et donc, il nous suffit de cliquer dessus pour retrouver chaque session. Ici, on va actualiser la page parce qu'on a changé de base de données. On a maintenant deux sessions qui sont ouvertes pour l'utilisateur Virgile arobase algomax point f r.

03:14 Il nous suffit maintenant de retourner sur vscode, de lancer la commande NPM rundev comme ceci pour lancer le projet sur le port trois mille. Et maintenant, on peut y accéder sur notre navigateur. On a donc notre application et on peut voir qu'on est déconnecté. Et pour se connecter, il nous suffit de rentrer notre email et le mot de passe ABC un, deux, trois. Et là, on peut voir qu'on est connecté à notre application.

03:35 Alors, qu'est-ce qui a changé Qu'est-ce que j'ai rajouté depuis la dernière fois Eh bien, si on retourne sur le fichier login point TSX, on peut voir qu'il y a eu plusieurs changements. Le premier changement, c'est que nous avons créé un composant réutilisable qui s'appelle field ici et qui prend en paramètre des props d'un inpôt, des props d'un label et une liste d'erreurs. Tout est regroupé dans un div va contenir notre label, notre input et une liste d'erreurs comme ceci. Maintenant, si on accède à cette page en étant déconnecté, on peut voir que c'est ce composant-là que nous avons créé. On a donc le label ici et l'input.

04:12 Et si on tape un mot de passe et un email erroné comme ceci, on verra un message d'erreur en dessous de notre input qui correspond à ce u l que nous retrouvons dans notre composant. Ce qu'on a fait également, c'est qu'on a remplacé l'élément forme natif à React à l'élément forme qui est un composant qu'on importe depuis Remix. Vous pouvez le voir jusqu'ici dans cette import. On importe forme avec un f majuscule depuis remix run, slash react, ce qui va permettre à remix de s'occuper et de gérer la navigation parce que nous avons retiré l'action sur notre route hausse login. Pourquoi on a retiré cette action Tout simplement pour dire que le poste s'effectue sur la même route, c'est-à-dire sur la route login point TFX et la logique, eh bien, elle se trouve dans le même fichier.

04:59 Ici, on exporte une fonction s'appelle action à l'intérieur de notre route login. Ce qui signifie que quand on va soumettre le formulaire en cliquant sur notre bouton de type submit, ça va donc soumettre chacun de nos champs et ça va ensuite exécuter notre méthode action ici. Alors au final, qu'est-ce qui se passe à cet endroit On récupère le form data, c'est-à-dire la valeur de chacun de nos inputs qui viennent d'être soumis dans ce formulaire. Et ensuite, on récupère un objet de type Sub Michel. Effectivement, ce code n'est pas du tout lisible, mais vous allez comprendre très vite que rajouter ce code va nous permettre d'améliorer considérablement l'expérience utilisateur.

05:38 Effectivement, ce qu'on a, si on fait un console log de notre forme data, nous avons donc un form data. On ne pourra pas le console log, mais on peut le transformer en objet en faisant un object point from entries comme ceci. Maintenant, ce qu'on va faire, c'est qu'on va return early pour ne pas exécuter la suite et ne plus connecter l'utilisateur temporairement pour expliquer ce qui se passe. On ouvre donc un terminal et si on effectue une soumission ici, en cliquant sur se connecter, on retrouve donc le Constle log avec chacun de nos champs, c'est-à-dire l'email et le mot de passe. Bien sûr, il serait totalement possible de récupérer les informations.

06:12 Par exemple, const email est égal à forme data, on guette email et ensuite ajouter une regex pour valider l'email et si l'email n'est pas valide, on pourrait par exemple trop une erreur, l'e-mail n'est pas valide comme ça. Sauf qu'on ne va pas du tout faire comme ça parce que ça impliquerait qu'on implémente manuellement à la main chacune de nos erreurs, c'est-à-dire est-ce que l'email est valide ou pas Et on devra ensuite côté client afficher ce message d'erreur en dessous de notre input. Sauf qu'on n'a pas envie de réinventer la roue. Effectivement, on utilise une librairie qui va se servir de Zod pour valider nos données. C'est pourquoi dans ce fichier, on peut voir qu'on importe une méthode qui s'appelle get zond string et une autre méthode qui s'appelle parse with zod qu'on importe depuis une librairie qui s'appelle conforme.

06:57 Et on importe également depuis cette librairie un hook qui s'appelle use form ainsi que deux méthodes getform props et get input props. Cette librairie s'appelle Conform et vous pouvez y accéder sur le site Conform point guide. En gros, elle nous permet de valider nos données de formulaires de manière en utilisant les web fondamentals et ils supportent les deux frameworks remix et Next de JS. Comment ça marche Regardons ensemble. On récupère donc notre forme data, mais on ne le convertit pas en tant qu'objet.

07:27 À la place, on va laisser conforme utiliser notre schéma Zod et il va prendre en premier argument le form data et en deuxième argument notre schéma Zod. Si on regarde côté client, il se passe à peu près la même chose. On appelle la méthode par Swift Zod qui prend un premier argument, notre form data et un deuxième argument un schéma zod. Si on clique sur le schéma zod, on peut voir qu'il ressemble à ça. On a donc un objet avec une propriété email de type string et ensuite de type email et l'on a également une propriété password qui est un string.

07:58 Et avec Zod, on peut choisir les messages d'erreur qui apparaissent en cas d'erreur au niveau de la validation. Ce qui rend Zod très utile, mais conforme nous permet de faire bien plus que ça. Parce qu'effectivement, on a là notre schéma Zode, mais ensuite, on le super griffine. Et le super griffine, ça va aller le modifier et ajouter encore un morceau de logique que cette fois, on code nous-mêmes pour ajouter une nouvelle étape à cette validation. Alors vous allez me dire pourquoi est-ce qu'on n'a pas rajouté cette étape directement dans la déclaration du formulaire ici Par exemple, on pourrait très bien rajouter le super refine à cet endroit-là et ensuite côté serveur, on pourrait supprimer tous ces morceaux de logique comme ça et ça serait quand même beaucoup plus lisible.

08:40 Mais le problème, c'est qu'on ne peut pas parce que effectivement, ce morceau de logique asynchrone s'exécute côté serveur. Et ce qu'on fait actuellement à ce niveau-là, c'est qu'on regarde tout simplement si l'utilisateur, il existe déjà. Donc, on contacte notre base de données et on lui demande est-ce que l'utilisateur existe S'il existe, on va donc renvoyer un message d'erreur. Par contre, côté client, on n'aurait pas eu accès au contexte et à la base de données, forcément parce qu'on ne partage pas les variables d'environnement et les codes d'accès à notre base de données, ça aurait été une faille de sécurité de le faire. Par contre, cette logique de valider l'email si c'est un string et si c'est un email fonctionne très bien côté client ici dans notre formulaire.

09:18 Du coup, on donne à Zode ce schéma et grâce aux props qu'on renvoie sur le formulaire et sur chacun de nos champs avec les méthodes getform props et get input props, ça va permettre à Conform de contrôler chacun des et l'état du formulaire. C'est-à-dire que quand on va cliquer sur se connecter avant même de soumettre le formulaire, comme on pourra le faire avec la méthode on submit, ça ne va pas le soumettre, ça va d'abord le valider avec la méthode on validate et ça va vérifier que l'e-mail est bien valide. On peut faire un essai ici, on va ouvrir l'inspecteur dans network et si on tape un email qui n'est pas du tout valide, comme ça, on peut voir que ça m'affiche donc un message d'erreur, cet email est invalide. Et on peut voir dans network que ça n'a fait aucun appel côté serveur parce que ça n'a pas soumis le formulaire. Effectivement, ça a exécuté la méthode on invalidate, sauf que la méthode on invalidate a renvoyé des erreurs, parce que le formulaire n'est pas conforme, donc on n'a même pas appelé notre backend avec des données erronées.

10:18 Ce qui veut dire qu'on économise donc des ressources, de la puissance de calcul, vu qu'on évite à notre back end de faire un traitement qui retournera de toute manière une erreur. Par contre maintenant si on renvoie un email qui est valide comme ceci, on clique sur se connecter et cette fois, si on sélectionne les méthodes, on peut voir qu'on fait bien un poste sur la route login et qu'elle renvoie une erreur avec notre pay-down. Effectivement dans ce cas-là, c'est le mot de passe qui est invalide. Et la logique de ce traitement côté serveur s'effectue dans notre super resign ici et ça nous permet en fait d'ajouter des messages d'erreur en dessous de nos composants. Parce que, comme vous pouvez le voir ici, grâce au hook use form qui est aux deux paramètres que nous avons rajouté à cet endroit-là, en gros, ce qui se passe, c'est que quand on valide le formulaire côté client, on ne fait aucun appel au serveur.

11:05 Donc, c'est la méthode on invalidate qui va afficher les erreurs à chacun des fils ici. Par contre, quand on soumet le formulaire, le serveur va nous renvoyer une réponse ici qu'on a appelé Result et qu'on récupère dans le action data et le use action data est un hook de remix qui nous permet de récupérer les données côté serveur. Donc si on regarde ce qui se passe ici, on peut voir qu'on récupère notre subméfiant et si notre submission status n'est pas égal à succès, donc s'il y a eu ne serait-ce qu'une erreur dans notre validation, alors on va voir un objet resolve qui va contenir la réponse de notre submission. Et c'est dans cette réponse que va contenir toutes les erreurs côté serveur et conforme. Il va ensuite les afficher côté client pour informer l'utilisateur qu'il y a eu des erreurs à corriger.

11:50 Et comme vous pouvez voir, c'est très intelligent parce que quand on soumet le formulaire, en cas d'erreur, ça va focus l'input qui est erroné. Maintenant, si on passe cette condition, c'est que toutes les validations ont réussi et dans ce cas-là, on est safe et on peut connecter l'utilisateur. Mais on peut le connecter seulement parce que son email est valide et cette vérification-là, on l'a effectué à cet endroit-là en récupérant l'email et le mot de passe qui ont été soumis et qui ont été validés par notre schéma, mais on rajoute une validation dans le super refail qui va tout simplement check if user existe. Et on peut regarder l'implémentation de cette méthode côté client. On a donc créé cette méthode côté client dans le service hausse service ici, et cette méthode prend trois paramètres, un email, un mot de passe et un booléen qu'on utilise pour valider ou non le mot de passe.

12:41 Le premier morceau logique, c'est de vérifier que l'utilisateur existe. On fait donc un fun unique et si l'utilisateur n'existe pas, on va renvoyer erreur à trou et un message de type l'email est invalide. Maintenant, si on rajoute with password, ça veut dire qu'on aimerait valider aussi le mot de passe, mais on ne valide pas le mot de passe lorsque l'utilisateur s'inscrit parce que l'utilisateur ne va pas définir de mot de passe à ce moment-là. Donc on valide le mot de passe en cas de connexion et on utilise la méthode compère depuis bcrypte à cet endroit-là pour comparer le mot de passe h et avec le mot de passe en clair que l'utilisateur vient de soumettre. Bien sûr, si le mot de passe est invalide, on va également renvoyer une erreur de type le mot de passe est invalide.

13:24 Sinon, si with password est à false ou que le mot de passe est valide, dans les deux cas, nous allons renvoyer l'utilisateur existe et error à false. Donc, dans le cas de notre connexion, si l'erreur est à false, alors on peut se connecter parce que le mot de passe a été validé et l'e-mail a été validé. C'est exactement ce qu'on fait à cet endroit-là. On appelle donc notre méthode checklyfuser existe et on passe en argument l'email avec la vérification de mot de passe qui est activée et le mot de passe en clair. Si la validation nous renvoie ne serait-ce qu'une erreur, alors dans ce cas-là, on l'ajoute en tant que dans conforme, ce qui va permettre à conforme de l'afficher ici dans notre input.

14:03 Sinon, s'il n'y a pas d'erreur, on ignore cette condition et on ignore cette condition vu qu'on a un statut de Success. Comme on a un statut de Success, on peut ensuite récupérer l'email de notre submission point value qui nous permet d'accéder aux données qui ont été parcées et validées par Conform et Zones. Et ensuite on utilise la méthode authenticate user qui nous renvoie un token permettant de connecter l'utilisateur comme ceci. Dans la dernière vidéo, ce qu'on avait fait, c'est qu'on validait directement les mails et nos mots de passe, pas dans une route remix, mais directement dans notre contrôleur Nestu JS comme ceci. Ici à l'époque, on avait une route qui s'appelait login et qui récupérait l'email et le mot de passe dans un local haut de gamme comme celui-ci et c'est à cet endroit qu'on gérait la logique tout simplement dans la local stratégie.

14:51 Ici, on faisait une validation et on demandait à Prima de nous valider le mot de passe et l'adresse email. Sauf que faire cette requête, l'API de Nestle JS nous faisait quitter cette page ici, ce qui réinitialisait donc chacun des formulaires parce qu'on accédait à une route, par exemple authentiqueate, comme ça, et on avait un message d'erreur au format json, ce qui n'était pas une bonne expérience utilisateur parce que l'utilisateur voyant cette erreur, il ne peut pas revenir en arrière et il va avoir la flemme de re-remplir son email son mot de passe. Maintenant, si on a déplacé toute cette logique de validation de connexion dans notre composant remix et qu'on a téléchargé de librairies supplémentaires donc ZOD et conforme, c'est d'un côté pour nous simplifier la vie parce que la gestion des erreurs sera la même sur toutes nos pages et c'est aussi pour simplifier la vie de l'utilisateur. Si je tape un mot de passe erroné comme celui-ci, on peut voir qu'on reste sur la page et les inputs ne sont pas réinitiisés. Ça veut dire que l'utilisateur sait ce qu'il doit modifier et pour garder donc son mot de passe, il peut retaper son mot de passe, il n'a pas à retaper son email.

15:54 Et c'est vraiment un step-up en termes d'expérience utilisateur parce que notre utilisateur, il va être heureux de ne pas avoir à remplir un formulaire à nouveau. Et ce qui est cool, c'est que j'ai également mis en place cette logique sur la page d'inscription ici. Donc, on peut voir qu'on a exactement le même formulaire qui utilise les mêmes inputs. On va ouvrir le code à côté à ce niveau-là et on peut voir qu'on a donc trois inputs, un inputs qui récupère le prénom, un qui récupère l'e-mail et un qui récupère le mot de passe. Et tout ça, bien sûr, c'est encore une fois géré par Conform.

16:23 Ce qu'on va faire, c'est qu'on va décommenter ces lignes-là. Encore une fois, on utilise Conform sur cette page pour booster l'expérience utilisateur. Je vais vous montrer un deuxième exemple. Ici, j'ai envie de créer un compte. On va donc m'appeler Virgile algomax point f r et je vais taper un mot de passe comme ceci.

16:38 Et si je clique sur je crée mon compte, là, on peut voir un message d'erreur directement en dessous du champ qui a posé problème. Là, on peut voir cet utilisateur existe déjà et c'est génial. Je le trouve parce que cette validation, elle a été faite côté serveur et pas côté client parce qu'on vérifie en faisant un appel base de données on regarde si l'utilisateur existe et s'il existe alors Zod renvoie une erreur à conforme et ensuite conforme nous affiche cette erreur en dessous de notre input. Ce qu'on aurait pu faire à cet endroit, c'est de rajouter une deuxième erreur à ce niveau-là, par exemple sur le nom, donc sur le nom, si on regarde le schéma, le nom, la propriété du nom s'appelle name à cet endroit-là. Donc côté serveur, ici, on aurait pu rajouter unishio avec comme chemin le nom de la propriété et on aurait pu mettre en récupérant donc les données qui ont bien été validées par zone, name et déjà utilisées par exemple, ce qui est évidemment improbable comme erreur et pour aller encore plus loin dans l'improbabilité, on pourrait rajouter ça sur la propriété password password et pas très safe comme mdp et en fait si on soumet à nouveau le formulaire comme ceci, on peut voir qu'on a une erreur sur chacun de nos inpots, c'est-à-dire qu'ils sont tous erronés et ça, c'est grâce à Conform et à Zod.

17:53 Parce que Conform, il a généré cette erreur-là et il va ensuite renvoyer toutes nos erreurs côté client. Et ensuite côté client, on n'a rien de plus à faire que de récupérer ce tableau d'erreur pour chaque propriété et de le passer ici dans notre input fields à cet endroit-là et de boucler dessus. Et ce qui est génial, c'est qu'on peut évidemment avoir plusieurs erreurs. Effectivement, c'est donc un tableau d'erreur. Donc, on peut avoir comme ceci trois erreurs sur le même formulaire et c'est vraiment un step-up en termes d'expérience utilisateur parce qu'on ne réunifieise pas les champs du formulaire.

18:26 Du coup, l'utilisateur, il peut constater son erreur et il peut tout de suite la corriger. Ce qu'on va faire maintenant, c'est qu'on va retirer ces erreurs qui semblent de toute manière uniquement à titre d'exemple et on va de nouveau analyser ce fichier. On utilise donc le composant use form qu'on importe depuis la librairie qu'on forme et ça prend trois paramètres. Le last result récupère donc la réponse du serveur, c'est-à-dire est-ce que les données ont été validées ou non Effectivement, le serveur leur envoie une réponse seulement si les données n'ont pas été validées dans ce cas-là avec cette condition-là. Donc si le statut de la sommation n'est pas égal à Success, alors on envoie nos réponses avec toutes les erreurs.

19:05 Sinon, on effectue une redirection. Du coup, les types ne sont pas inférés par cette méthode. Ensuite, le deuxième paramètre, c'est comme pour la méthode de connexion, on utilise donc le on validate, ce qui nous permet côté client de récupérer le form data. Le form data contient donc toutes les informations de notre formulaire et ensuite, deuxième paramètre, on donne un schéma ZAD qui ressemble à celui-ci. Ça prend donc un email, un password et un AM.

19:30 Ce qui est génial avec Conform, c'est que si demain on change la propriété name ou qu'on appelle ça first name comme ceci, on peut voir qu'on a un problème à ce niveau des types parce qu'on a détecté ce changement côté client. Du coup, il nous suffit juste de corriger notre erreur comme ça et maintenant c'est bon. Et côté serveur, on a également le même problème, first name, name, donc on peut tout de suite refactoriser notre code à tous les endroits qui faisaient référence à ce schéma ZAD. Ça, c'est pour la validation côté client. Ensuite, la validation côté serveur lorsqu'on soumet notre forme sans déclarer une action ici, parce qu'on veut rester sur la même page, on exécute la méthode qui s'appelle action ici, ce qui nous permet de récupérer les données du formulaire dans le request point forme data et d'effectuer une validation en utilisant par Swift zone qui est donc cette librairie de conforme qu'on a vu tout à l'heure.

20:22 Et cette fois, comme les appels de bases de données sont asynchrones et comme notre serveur doit contacter notre base de données, notre base de données doit renvoyer une réponse positive ou négative, on transforme cette validation en validation asynchrone en rajoutant le mot clé await qui n'est pas du tout nécessaire. Par exemple, à cet endroit-là, le Parso isod n'est pas un synchrone parce qu'on valide à l'instant t les données. Ici, ce qui nous pousse à faire une validation asynchrone, c'est cet appel avec notre base de données à cet endroit-là. Sinon, on aurait tout simplement pu valider notre formulaire. Comme ceci, en asynchrone, en faisant la même validation que le client et ça aurait été exactement la même logique.

21:01 Mais comme la validation est asynchrone, on doit passer le mot clé async et on doit await la méthode par swiss z. Maintenant, vous pouvez voir que lors de la méthode register et lors de la méthode login, dans les deux cas, ce qu'on fait, c'est qu'on fait une redirection sur une route qui s'appelle authenticate avec un token de sécurité. Ce token, c'est le session token et on l'avait mis en place ensemble dans la vidéo précédente. Dans notre schéma Prisva, nous avons donc un modèle session qui va contenir toutes les sessions utilisateurs et ça va contenir un session token qui va permettre de connecter l'utilisateur à sa session. On redirige donc sur la méthode authentiqueate ici qui se trouve dans le haut contrôleur.

21:43 On déclare donc une route qui s'appelle authentique. En cas de succès, on redirige sur la page d'accueil de notre application qui est donc cette page-là, mais cette route est protégée par un local Osgard, ici. Le local Osgard, nous l'avons mis en place ensemble dans la vidéo précédente. Le local Osgard a besoin d'avoir dans la request un email et un password, c'est pourquoi nous avons besoin de le préciser en dur comme ceci, ce sont des fausses informations, mais elles sont nécessaires pour pouvoir valider la suite des opérations. En fait, c'est une fausse logique qu'on a rajouté, mais la vraie logique se trouve dans la locale stratégie ici, parce qu'on a donc une stratégie locale qui est utilisée de pair avec le ici et cette stratégie locale va nous permettre d'exécuter la méthode validate.

22:30 On récupère donc notre request depuis la SEGS et cette request est accessible grâce à ce paramètre qu'on a rajouté le pass request to call back qu'on a mis à true ici dans la méthode super du constructeur. Ensuite, on récupère donc dans notre request le token qui est donc un paramètre du r l ici, on a donc un token égal à un deux trois comme ceci par exemple et on vérifie que cette session existe bien. Si elle n'existe pas, on renvoie une erreur à notre utilisateur. Votre session a expiré, veuillez vous reconnecter. Sauf qu'on n'a pas envie de laisser l'utilisateur sur une erreur JSON.

23:05 Ici, par exemple, si on envoyait n'importe quelle erreur, méthode not in playantent tel par exemple, et qu'on accède à la route slash authenticate comme ceci, là, on aurait une erreur sous forme de json. Et encore une fois, ce n'est pas top pour l'expérience utilisateur. On n'a pas envie de montrer cet écran à nos utilisateurs. Donc à la place, ce qu'on fait, c'est qu'on renvoie une erreur, mais on effectue également une redirection ici. Et cette erreur, nous l'avons implémenté nous mêmes.

23:29 On a appelé le fichier redirected-erreur. Exception. T s. Il se trouve ici dans SRC et nous faisons un exten de http exception qu'on importe depuis Nest. Js.

23:42 C'est donc une classe qui prend deux paramètres dans son constructeur, le message d'erreur et l'url de redirection. Et on appelle ensuite la méthode super avec le message et le statut de la redirection. Ce qui nous permet d'utiliser dans notre application le redirect exception comme ceci. Mais ce n'est pas le seul morceau de logique qui nous permet de l'utiliser. On a également dans le fichier main point t s, utilisé ce qu'on appelle un global filter ici et vous pouvez regarder la documentation pour le site de Nest JS en tapant Nest JS exception filter ici, on a une doc très complète à ce niveau-là qui nous explique qu'on peut implémenter nous-mêmes nos propres exceptions ici.

24:21 On peut voir donc on fait un de l'HTTP Exception Filter, et si on fait une recherche de ce http Exception Filter, on peut voir qu'on implémente nous-mêmes ce filter qui va à cet endroit-là catch toutes les exceptions et on peut rajouter un morceau de logique particulier pour chacune des erreurs que nous avons créées. Ici par exemple, on a notre fichier qui s'appelle Exception Filter à cet endroit-là et j'ai copié exactement le code qu'on retrouvait sur la doc de Nest JS, mais à cet endroit-là, j'ai rajouté une condition si l'exception est de type redirect exception, dans ce cas-là, j'implémente la logique j'aimerais qu'il se produise, c'est-à-dire effectuer une redirection deux-cent-deux sur l'URL de redirection avec le message d'erreur dans l'URL. Maintenant, ce qui se passe si on accède à la route avec un token qui est faux comme ABC, on peut voir qu'on est redirigé à cet endroit-là avec cette url-là. Cette url contient donc l'url de redirection qui est la page login avec le message d'erreur votre récession a expiré, veuillez vous reconnecter. De cette manière, on pourrait côté client afficher cette erreur sur une interface qui sera plus ergonomique et donc ça améliorerait l'expérience utilisateur.

25:31 Ensuite, dans le cas d'une connexion réussie, ici, on supprime cette session qui était en fait un code à usage unique et on renvoie les mails et le user ID dans la session, ce qui va authentifier l'utilisateur dans Redis ici et ça va donc créer une nouvelle entrée de type session. On va le faire tout de suite. On va supprimer les deux sessions qui sont présentes dans cette base de données et on va se connecter avec l'utilisateur qui existe. On se connecte et là on peut voir qu'on est donc identifié, on peut voir notre belle nappe var. Si on retourne dans Release et qu'on actualise, on peut voir qu'on a notre nouvelle session à cet endroit là et on a bien l'e-mail et l'ID qui ont été sélectionnés si on retourne dans VSCD ici peut voir que ça correspond au champ qu'on a renvoyé à cet endroit-là.

26:15 Maintenant, pourquoi on a implémenté l'authentification par token C'est aussi pour pouvoir authentifier les utilisateurs grâce à l'adresse email, mais sans forcément demander un mot de passe. Par exemple, il existe plein de sites e-commerce lequel il est possible de passer une commande sans créer de compte et juste en fournissant notre adresse email. Et ce que certains de ces comptes font, c'est qu'ils vont même jusqu'à connecter notre compte client sans avoir défini de mot de passe. Par contre, ensuite, ils nous envoient par SMS ou par email un lien de connexion pour définir un mot de passe au bon vouloir du client. Ensuite, si on retourne dans le service Ospan Service, on peut trouver les autres méthodes que nous avons créées, la création du compte utilisateur.

26:53 On va donc utiliser des cryptes JS pour hacher notre mot de passe comme ceci et on crée l'utilisateur et on n'oublie pas bien sûr de transformer l'email en l'email en minuscule pour éviter toute erreur. Ensuite, la méthode authentique qui nous permet de créer ce token de connexion s'effectue avec cette logique. On passe donc un email et on crée une nouvelle session. Il prend en paramètre l'email et le session token que nous créons avec la méthode create ID. Et ça, c'est une dernière librairie que nous venons de télécharger cette fois dans Nest.

27:26 Js ici, ça s'appelle parallèle drive slash quaid deux. Pour la retrouver, ce qu'on a fait, c'est qu'on a tapé npm g s quaid ici et on avait un message d'erreur qui nous disait qu'elle était dépréciée. Nous recommandait d'utiliser parallèle drive slash quaid deux, qui est cette librairie qui a été téléchargée deux-cent-quarante-mille fois cette semaine et qui nous permet très facilement de générer un token à usage unique avec la méthode Create ID. Maintenant ce qu'on a envie de faire, c'est de mettre en ligne cette application et de vérifier que ça fonctionne très bien. Dans la vidéo précédente, j'avais tenté de la mettre en ligne et j'avais eu une petite erreur au niveau de la.

28:05 Ici, l'erreur, elle était toute bête, c'était la méthode tape check qui n'avait pas détecté la fonction Gatello qu'on importait sur le fichier qui s'appelle api point TFX. Effectivement, si on regarde dans les fichiers modifiés ici, on avait un fichier api point TFX qui récupérait depuis le remix service une méthode qui s'appelait Gatilo qui était une méthode de test qu'on avait implémenté au tout début mais qu'on avait ensuite supprimé. Maintenant j'ai supprimé donc le fichier api point tsx et ce que je peux faire, c'est faire un npm run type check à la racine pour vérifier qu'on n'a aucune erreur au niveau de notre type. Ça m'a l'air d'être bon. Un npm run Lint comme ceci pour vérifier en local si on a des problèmes avec e s int ou avec check, on peut voir qu'on a eu une petite erreur avec e s int, ça va donc poser problème durant notre C I.

28:50 Ici, effectivement, on récupère la request, la méthode authentique et on n'en fait rien parce qu'on effectue une redirection sur la homepage. On peut retirer ces commentaires-là. Ils étaient utilisés à l'époque pour faire un console log de l'utilisateur qui est présent dans la requête. Maintenant, si on réeffectue un NPM run lint, je pense qu'on a corrigé toutes nos erreurs e s lint. Bien sûr, on a des petits avertissements, mais ce n'est pas nécessaire pour nous de les corriger.

29:14 Bien sûr, ce qu'on a fait la dernière fois, c'est qu'on a rajouté Prisma dans le fichier dockerfile parce qu'on utilise maintenant une base de données s'appelle schéma. Prisma. Donc, si on regarde le dockerfile à cet endroit là, on peut voir qu'on avait ces deux lignes, la trente-neuf et la quarante qui étaient commentées. En fait, ils étaient commentées et on les a décommentés parce qu'on veut rajouter maintenant le fichier, le dossier Prima dans le dossier Prima de notre machine virtuelle et ensuite on veut faire un cd dedans et lancer la commande NPX prisma générique comme ceci. On génère donc les types et les fichiers d'exécution de prisma pour qu'on n'ait pas d'erreur lors du déploiement de notre application.

29:51 Maintenant ce qu'on peut faire, c'est qu'on peut rajouter les changements qu'on a fait et ensuite on peut les commit en appelant add register out par exemple et on peut ensuite push sur notre branche zéro quatre authentification. À ce niveau-là, on va regarder maintenant les actions. Il n'y a pas d'action parce que les actions sont effectuées seulement quand on fait une poule request. Ok, donc là, on peut voir que ça a pris au total deux minutes quarante de valider toutes les étapes e s lint, le script et le build de notre image. On va regarder maintenant si c'est disponible en production sur l'adresse ou le pouce en varcov point f r.

30:23 On peut voir que là, ça prend quand même beaucoup de temps à charger la page. Donc il a dû se passer peut-être une erreur. Donc ce qu'on va faire, c'est qu'on va se connecter au serveur directement et on va essayer de comprendre ce qui s'est passé. En premier, on peut faire un docker PS pour lister toutes les images docker. Ici, on peut voir qu'on a donc bien redis qui a été créé il y a deux minutes et on a aussi le NSJS tiret remix tiret mono repos qui a également été créé.

30:48 Par contre si on fait un docker log de cette image là donc NSJS tiret remix comme ceci, on peut voir ici qu'on n'a apparemment aucune erreur, le projet s'est bien lancé, qui est assez étrange, si on fait un tiret f, on peut même suivre les logs de notre application ici. Alors c'est vrai que dans la dernière vidéo, ce que j'ai oublié de vous dire, c'est que ici dans v s code, le docker compose point prod, il contient un volume pour persister les sessions utilisateurs. Parce que s'ils ne contenaient pas de volume, en fait, la base de données serait recréée à chaque fois et on perdrait toutes les données. Donc ce qu'on a fait, c'est qu'on a bindé un volume sur le disque dur de notre VPS pour le bindé au slash data de notre instance et dix à cet endroit-là. Donc si on retourne maintenant dans le terminal, ici on a ce chemin-là, donc on peut ce chemin-là, on peut faire un CD à l'intérieur.

31:36 Le fichier dev existait déjà, mais dedans, on a créé le dossier volume dans lequel on peut naviguer maintenant et si on continue de faire des cd, on peut voir qu'on retrouve bien notre chemin complet qui était celui-là. Ce qu'on a fait pour créer ce fichier, c'est qu'on est allé dans le fichier HCD, on va donc faire un m k dire tiret p de notre dossier comme ceci. Bien sûr, on a utilisé sudo comme ceci et ce qui est ce que ça fait, c'est que ça crée de manière récursive un dossier comme ça de notre dossier comme ceci. Donc ça marche plutôt très bien. Maintenant on va quand même supprimer ce fichier-là qui servait à titre d'exemple, mais on possède donc bien un fichier session dans notre dossier production en ici.

32:18 On peut même faire un cd dedans comme ceci et si on fait un l s, on peut voir qu'il n'y a absolument aucun fichier à l'intérieur. Ça veut dire que Redis n'a rien créé pour le moment comme donnée. Le problème vient peut-être de là, parce qu'on peut voir à ce niveau-là qu'on n'arrive pas à se connecter en fait. Si on fait un check-host du site à cet endroit-là, on peut voir qu'on détecte bien notre serveur Hostinger sur le port quatre-vingt-cinq trente-et-un deux-cent-trente-neuf soixante-dix-sept et si on réaffiche notre configuration caddie ici on peut voir à cet endroit-là que cette url-là on la redirige bien sur le port trois-mille. Si on refait un docker PS à cet endroit-là on peut voir qu'on bin bien le port trois mille au port trois mille de notre application.

32:59 Ce qu'on peut faire vu que ça ne marche pas, c'est qu'on peut retirer ce volume et voir si ça venait vraiment de là. Maintenant il y a aussi une deuxième erreur qui me gêne quand on fait un NPM Roundev ici, c'est qu'on a ce message d'erreur qui dit ready seasal ready connecting slash connectd. Et en fait dans le main point t s, ici au moment de créer le store et le ready client, on n'est pas obligé de rajouter ce mot-clé point connect ici, parce qu'en fait, il se connecte directement automatiquement. Donc, ce qu'on peut faire, c'est qu'on peut quand même rajouter les log d'erreur en rajoutant on erreur console. Error comme ça et on peut également rajouter un on connect comme ceci et afficher par exemple connecter de tourillis.

33:39 Maintenant si on rafraîchit la page, on peut voir que le message d'erreur, il est parti et qu'on a plutôt le console log connecté de tourillis et on peut donc supprimer cette ligne là. Maintenant bien sûr, à cet endroit là, il faut bien qu'on soit sûr de rajouter le secure quand on sera en environnement de production sur notre serveur ici. En fait, si on rajoute le secure comme ça, ce que ça va faire, c'est qu'on ne pourra plus se connecter en local et si on le rajoute avec un process .invi. Node, nv est égal à production, quand on va exécuter le fichier en local à l'intérieur de notre dockerfile, malheureusement ça considérera qu'on est en environnement de production. Et ce qu'on peut faire, c'est qu'on peut quand même rajouter le secure comme ceci et dans le docker compose en dev ici, on peut forcer l'environnement de développement pour que ça ne sécurise pas le cookie si on est en local.

34:27 Pour rappel, ce qu'on vient de faire pour déboguer à cet endroit-là, c'est qu'on a retiré le volume de Redis. Maintenant, on va réeffectuer une mise en production remove Redis volume et on va de nouveau faire un push sur cette branche zéro quatre authentification et on va de nouveau créer une poule request sur la branche main à partir de cette branche zéro quatre authentification. Et on fait tout ça parce qu'on a envie de débugger ensemble notre application qui a l'air de ne pas se charger. Maintenant on va retourner dans les actions et attendre patiemment que le build s'effectue. Ok donc le déploiement vient d'être terminé, On peut retourner côté serveur et faire un docker ps pour vérifier que ça a bien recréé chacune des images et on peut même afficher le nouveau log notre application.

35:10 Et on peut voir que le correctif qu'on a rajouté a bien été effectué. Donc, on a notre log connected tourillis. Si maintenant on essaie d'accéder au site coup de pouce en barkhov. Fr comme ceci, on peut voir qu'on n'arrive vraiment pas à y accéder. J'ai l'impression qu'il y a une sorte de fuite mémoire et que ça fait cracher tout.

35:26 Mais le problème, c'est qu'on n'identifie pas le problème parce qu'on n'a aucun log à ce niveau-là et on est sûr maintenant que ça ne vient pas du volume de Redis. Ce qu'on peut faire du coup pour débloquer, c'est qu'on peut exécuter le docker en local. Ici, donc c'est le fichier dockercompose. Dev. Yaml avec un up tiret tiret build, Mais avant de l'exécuter en local, ça va faire un clash avec cette version de Eurylis standard-one.

35:49 Donc, on va stopper chacun de nos conteneurs comme ça et maintenant on peut lancer la commande en n'oubliant pas le point diaml comme ceci. Ok, donc là on vient d'exécuter notre application en local avec docker. Va se connecter au local trois-mille voir si ça fonctionne on peut voir en local que ça a fonctionné maintenant on va on va tester une connexion ici cliquant sur login, ABC un, deux, trois. Là, on peut voir qu'on réussit bien à se connecter. Si on clique maintenant sur la page login pour essayer d'y accéder, on est redirigé sur la page d'accueil.

36:18 C'est un morceau de logique qu'on avait également rajouté et si on se déconnecte ici, ça fonctionne plutôt bien. On va essayer de créer un nouveau compte. Voilà Alfred par exemple ABC un deux trois virgile trois arobase alocomax point f r et là je suis bien connecté en tant qu'Alfred. Donc ça, ça marche, ça marche en local. Je pense que le problème ne vient pas du volume.

36:37 Donc, on peut décommenter cette partie du fichier dockercompose. Prod à cet endroit ici. Si on regarde les performances de notre serveur en exécutant la commande hash top, on peut aussi exécuter un top comme ceci, on peut voir qu'on n'a pas l'air d'avoir trop de problèmes ici au niveau de la mémoire et du nombre de CPU et de leur réutilisation. Par contre là, je viens de faire un essai, je me suis connecté en http et pas en http s et là j'ai une erreur de type apachedefold deux it works comme ceci. C'est quand même plutôt pas mal bizarre.

37:08 En fait là on peut voir qu'on a un problème avec Cady serveur. Ou si on fait un sud status de Cady ici, on peut voir qu'il a fail et je ne comprends pas pourquoi on compte. Ce qu'on va faire, c'est qu'on va essayer de le débugger ensemble. Ici, on a donc notre projet coup de pouce en varcoff point f r. Et ce qu'on aurait envie de faire limite, c'est le http, pas le https du projet coup de pouce point varcoff point fr, on aurait envie de le rediriger avec un re direct comme ceci sur le site https double point coup de pouce point varcov point fr et ça serait exactement pareil pour les autres sites par exemple https avec un w coup de pouce point varcof point f r et un http comme ça avec un w point coup de pouce point varcof point f r.

37:51 Là ce qu'on est en train de faire en fait c'est qu'on est en train de prendre toutes les les URL qui sont possibles pour ce site et de les rediriger sur l'URL principale qui est donc celle-ci qui sera bien cette fois en HTTPS. Mais là, on doit quand même essayer de redémarrer ce fichier de configuration caddie, on peut voir qu'on a un problème à ce niveau-là. On a toujours notre problème et on a besoin de trouver d'où ça vient. On peut bien sûr ajouter le mot clé permanent comme ceci, mais au final, on peut aussi commenter ces dernières instructions pour voir si le problème vient de là. Ça n'a pas l'air de venir de là, car on a toujours l'erreur.

38:24 On va déboguer en live. On va faire un sudo apt full update ou plutôt un sudo apt update comme ceci pour installer les dernières mises à jour de quali de toutes les technologies qu'on utilise et ensuite on va faire un SIDO aP full tiret upgrade comme ceci. Cette fois ils vont nous dire qu'on a l'équivalent de deux cent trente méga octets de mise à jour à faire. Donc, on attend que ça mette tout à jour. Peut-être que notre problème vient de là, on espère en tout cas.

38:50 Ok, donc on a fini de mettre à jour notre serveur comme ceci, donc on va recharger tous les services ici, le service Apache, le service Chrome, le service multi pass, Le problème vient peut-être effectivement d'Apache en fait. C'est peut-être Apache qui a pris le dessus sur Caddy serveur. En fait, je crois même que c'est ça. Ici, si on fait un restart de Kady, on a toujours l'erreur. Par contre, si on fait un studio système CTL stop à page deux comme ceci et on refait un restart de caddie on peut voir que maintenant ça fonctionne en fait ça venait de là sur ce serveur j'avais utilisé apache à l'époque pour héberger un site WordPress et on peut voir qu'il a été réactivé au niveau peut-être d'une mise à jour.

39:29 Donc là, on va décommenter nos lignes et restart Caddy comme ceci et maintenant si on accède à notre site, là j'ai actualisé la page en en https et on peut voir qu'on a maintenant accès à notre application. En au final tout va bien, ça venait d'une erreur de configuration de notre part. Donc maintenant ce qu'on va faire, c'est qu'on va remettre dans le docker compose le volume. Ici, on va refaire une mise en prod. Oui fixed des erreurs comme ça et on va push sur la branche en question maintenant on retourne sur GitHub une dernière fois et on va de nouveau créer une pull request de la branche zéro quatre authentification sur la main comme ceci.

40:06 Ça y est, la CAA est bientôt terminée. On est à l'étape de déploiement et on va bientôt pouvoir tester la connexion et l'inscription en prod. Là, on peut voir que le déploiement s'est terminé, donc on va retourner sur notre site coup de pouce en barcov point f r. On est bien déconnecté, donc là ce qu'on va faire, c'est qu'on va cliquer sur connexion et on va se connecter avec notre compte ici. On peut voir qu'on a une petite erreur ici, on évolue login.

40:28 Donc, on va tout de suite regarder les logs côté serveur pour voir d'où vient cette erreur. En fait, elle vient du database URL qu'on a oublié de rajouter sur GitHub. Ça aussi, c'est une erreur très commune. On a besoin ici d'aller dans les settings et tout en bas, là dans on va dans action et à ce niveau-là, on doit rajouter un recozzi secret, donc ça sera database URL comme nom. Là, on va retourner dans notre fichier point en local ici et on va conserver cette URL de connexion qui nous permet d'accéder à notre base néon tech en production.

40:59 On fait ça comme ceci, donc on va coller ce secret automatiquement sur GitHub et comme on l'utilise à ce niveau-là au niveau de notre CAI au moment du build, ici, maintenant qu'on vient de le rajouter, on doit quand même également le rajouter dans les fichiers de mise en prod. À ce niveau-là, donc on va aller dans le build comme ceci et sinon l'action plutôt de déploiement, donc dans C I et dans cette dernière action-là, s'appelle Deepploy ici, on a des variables d'environnement. Donc, on peut voir qu'on a turbotoken et on a turbotam. Donc, pour le moment ici, vu qu'on fait conditionnellement une mise en staging, une mise en prod pour l'environnement de staging et une mise en prod pour l'environnement de production. Ici, on peut voir d'ailleurs qu'on utilise invi nord en v est égal à la production.

41:40 On va copier cette syntaxe turbotam ici et on va dire que le database underscore URL est égal au secret point database URL, qui est ce qu'on a sauvegardé à ce niveau-là. Donc ici, on a notre variable d'environnement de production. Donc maintenant, on peut encore une dernière fois cette fois, on espère mettre en prod add database url, on va faire un guide push comme ceci. Maintenant, on va de nouveau créer la pool request pour réexécuter chacune des actions. Sauf que cette fois, ça va sauvegarder notre secret de manière sécurisée et ça va la passer dans notre instance Docker.

42:16 Ici, si on retourne côté serveur, le meilleur moyen de savoir si toutes vos variables d'environnement ont été détectées, c'est de faire un Docker Inspect et le nom de notre image docker, on peut voir qu'on a donc neuf j s tiret remix ici, on va l'inspecter, neuf j s remix mono report, on va prendre le tiret prod comme ça et là, on peut voir qu'on a donc cette interface ici et on peut retrouver toutes les variables d'environnement. Donc on a le node qui est en production, on a le release URL qui utilise la bonne URL et on a donc d'autres variables d'environnement, mais on n'a pas le database URL qui devrait apparaître pour notre application pour se connecter à Prisma. Et après cette nouvelle mise en prod, il va apparaître quand on va faire un docker inspect. On peut pour le moment, au lieu d'afficher tout ça, utiliser la commande grep pour n'afficher qu'une partie. Si par exemple ici, je vais prendre le nom de redis underscore url comme ceci, ça va m'afficher la ligne qui a trouvé ce chemin là, donc le redis underscore url.

43:12 Maintenant, c'est un petit peu plus lisible pour nous de récupérer ces informations. Le déploiement s'est effectué. Si on fait un docker PS ici, l'instance a été recréée il y a vingt-six secondes et si on fait un de database url comme ceci, maintenant on voit cette variable de l'environnement qui a été rajoutée. Donc, on va refaire une tentative, on se reconnecte une fois sur le site et on essaye de se connecter à notre compte comme ceci. Maintenant, on peut voir que ça soumet le formulaire et qu'il y a un écran de chargement à ce niveau-là et on a de nouveau une erreur.

43:40 Donc comme quoi, ça sert à quelque chose de tester notre application. Et si on regarde les logs comme ceci, on peut voir qu'on a un message ici qui nous dise please make show your database serveur is running at EPR off fog donc qui est tout simplement l'adresse de notre base de données néon. Ce qu'ils sont en train de dire ici c'est que la base de données ne répond pas. Donc soit l'url n'est pas bonne, soit la base de données est en ligne. Donc ce qu'on va faire, c'est qu'on va se reconnecter à notre base de données si on est rond comme ça pour voir si elle a été mise hors ligne.

44:10 Il n'y a pas l'air d'avoir de problème à ce niveau-là. On possède bien toutes nos branches, toutes nos tables. Donc ce qu'on peut faire, c'est se connecter dans le terminal à notre image docker. Donc si on fait un docker PS ici, on peut voir que notre image docker c'est une FGS qui a un remix mono repos. Ce qu'on peut faire, c'est qu'on peut faire un docker exec qui aurait it pour interactive et le nom de notre image et dire qu'on veut se connecter à l'emplacement s h je crois comme ceci.

44:35 Là on peut voir que ça m'a ouvert un terminal à l'intérieur de l'application docker. Si on fait un ls ici, on a donc notre monoripo comme ceci et on peut tenter un cd backend et un mp x prisma migrate deploy pour voir si on a des erreurs ou pas et là on peut voir qu'on a donc cette erreur-là, il n'a pas trouvé le fichier skima point prisma pour exécuter cette commande. Pourtant, c'est étrange, on rajoute bien. Si on fait un l s tiret l ici, on peut voir que dans notre backend, on a donc un dist, un package point json et un start s h. Mais on n'a pas le fichier de la configuration Prizma.

45:08 Donc ça, c'est un problème, c'est un gros problème même. Donc si on retourne notre docker side ici, pourtant on avait fait un add de backend slash Prima dans backend slash prisma ici pour faire le NPM run build et ensuite générer les notes module, sauf qu'on a ensuite changé d'image ici on est on est retourné dans runner et à cet endroit-là, on n'a pas de nouveau copié le fichier dont on avait besoin. Donc, ce qu'on va faire, c'est qu'on va, là, on est donc dans l'action installeur et on va dupliquer cette ligne et on a envie de copier du coup app backend prisma, on va copier ça et on va rajouter prisma pour dire que c'est le dossier de prisma et on va le coller là-dedans comme ceci. Donc, on va faire un backend et on va remettre prisma comme ceci. On peut vérifier en local.

45:50 On peut vérifier en exécutant cette commande sans faire un bulle en local. Si on inspecte notre image ici, donc on va cliquer dans dev et dans files ici, on a donc tous nos fichiers et si on va dans notre app, on a un back-end et ici on peut voir qu'on n'a pas le dossier Prizma. Donc en fait, c'est totalement de notre faute, on a oublié de le rajouter dans le docker. Donc ce qu'on peut faire maintenant, c'est qu'on peut cette fois vérifier en local, on va rajouter le tiret tiret build, réeffectuer un build de Prima et cette fois rajouter ce dossier qu'on a oublié de copier. Ok donc là, l'image a terminé de build.

46:21 Si on regarde sur Docker desktop, on va réinspecter notre image, donc dans fichier toujours app back-end et là cette fois on voit le dossier Prima avec l'immigration et le schéma. Donc c'était une étape qu'on a oublié de faire. D'ailleurs, ce que je vous conseillerais de faire également, c'est de lancer la commande dans start point f h qui a été commenté d'ailleurs le NPX Prima Mygrade Deploy. Parce que si on avait exécuté cette commande, on aurait tenté de se connecter à la base de données, on aurait détecté le problème un un flipper plutôt. Donc là, on va rajouter add prima holder insight docker comme ceci et on va de nouveau mettre en prod et on va de nouveau créer cette poule request et à chaque erreur qu'on fait, on est obligé de répéter cette opération.

47:02 Vous voyez donc, on a bien fait de configurer les GitHub actions pour pouvoir déployer notre application à chaque fixe. Parce que comme ça, ça nous permet d'être très très rapide ici, on a juste à attendre que GitHub se charge de faire lead lint, le type script, le build et de déployer notre appli en prod. De notre côté, on a juste à réparer les bugs, à bien configurer et ensuite ça va bien fonctionner. Et l'action de déploiement, c'est maintenant terminé. Donc, on va faire un nouvel essai.

47:27 Ici, on va regarder les logs de notre serveur avec un docker log et on peut voir qu'on n'a donc aucune erreur. C'est plutôt bon signe. Maintenant, si on retourne sur notre projet, ici sur la page login on va retenter une connexion comme ceci et cette fois ça a fonctionné on est bien connecté on voit donc le nom du compte qui est connecté, ça s'appelle Virgile. On peut même voir les logs dans le terminal ici, les logs de connexion qui étaient donc dans notre local stratégie maintenant ce qu'on va faire c'est qu'on va s'inscrire on va donc créer un nouveau compte virgile quatre arobase algo max point FRABC un deux trois je crée mon compte et là on peut voir qu'on est toujours connecté cette fois donc l'inscription a bien fonctionné elle nous a également identifié et ça c'est vraiment super. On a terminé pour l'authentification.

48:15 Maintenant on va pouvoir passer à l'implémentation des premiers features de notre application comme lister des offres, rechercher des offres, et caetera. On se retrouve très bientôt pour le prochain module. A plus.