# Gladiator API and Front-end Ce TP a pour but de vous faire continuer l'API JSON Rails du TP4 et de vous familiariser avec : * Comment un écrire une page Web en Rails * Comment écrire un form * Comment gérer les sessions stateful dans un site Web * Comment gérer les sessions stateless dans une API ## Repartir du TP précédent ? Non, il faudra repartir de la correction présente ici: https://codefirst.iut.uca.fr/git/karim.bogtob/correction-tp-rails Petite note : Il y a maintenant dans les seeds de quoi générer des combats. ## Leaderboard On va maintenant construire un leaderboard des combats qui ont été réalisés et offrir de quoi faire une recherche de combats. C'est votre jour de chance, on vous fournit la vue pour vous faire gagner du temps. * Pour cela vous allez devoir coller le template suivant en tant que layout (`app/views/layouts/application.html.erb`) : ```erb Les joyeux de la couronne WEB <%= csrf_meta_tags %> <%= csp_meta_tag %> <%= stylesheet_link_tag "application", "data-turbo-track": "reload" %> <%= javascript_importmap_tags %> <%= yield %> ``` Voici la vue de la page, prenez le temps de lire le code et comprendre quels attributs devra posséder le contrôleur : ```erb

<% @combats.order(created_at: :desc).each do |combat| %> <% end %>

Date	Nom	Combatant 1	Combatant 2	Résultat	Gagnant
<%= l(combat.created_at, format: :short) %>	<%= combat.name %>	<%= combat.left_fighter.name %>	<%= combat.right_fighter.name %>	<%= combat.result.capitalize %>	<%= combat.winner&.name %>

``` * Créez ou générez un contrôleur `Leaderboard` avec une action index et la route correspondante. * Copiez le template du layout comme indiqué ci-dessus si vous ne l'avez pas encore fait. * Copiez le code fourni ci-dessus dans la vue correspondant à l'action index (`app/views/leaderboard/index.html.erb`) * Modifiez le code de l'action index du contrôleur pour fournir à la vue ce dont elle a besoin pour afficher les combats. * Faites fonctionner la recherche présente dans la top bar pour filter les combats en fonction de leur nom (comme on l'a déjà fait dans l'API) * Améliorez cette recherche pour chercher également dans le nom chercher également dans le nom de la créature victorieuse. * Vous pouvez appeler `#or` sur la première query et repasser une nouvelle query qui fait la recherche souhaitée. * Petite note : La jointure nécessaire devra se faire sur les deux queries, même sur la première qui ne l'utilise pas sinon elles seront structurellement différentes et ActiveRecord n'appréciera pas. * Eager loader les données pour limiter le nombre de requêtes * Vous pouvez constater dans les logs la différence de réponse de la requête : Avant : ``` Completed 200 OK in 75ms (Views: 67.7ms | ActiveRecord: 3.1ms | Allocations: 61092) ``` Après : ``` Completed 200 OK in 13ms (Views: 11.8ms | ActiveRecord: 0.7ms | Allocations: 9436) ``` ## Gestion des utilisateurs Nous allons ajouter à notre application des utilisateurs possédant un nom d'utilisateur et un mot de passe. Nous devons stocker ce mot de passe de manière sécurisée dans la base de donnée. Pour cela on va utiliser la méthode `has_secure_password` du module `ActiveModel::SecurePassword`. * Créez ou générez un modèle `User` possédant UNIQUEMENT un `username` de type `string`. On ajoute le mot de passe dans une étape suivante. * Faites en sorte qu'il ne puisse pas y avoir deux utilisateur créatures avec le même `username`. (Rappelez vous commment on a fait pour les créatures, deux choses à faire) * Lisez attentivement la documentation https://api.rubyonrails.org/v7.0.4/classes/ActiveModel/SecurePassword/ClassMethods.html, et adaptez votre code : * Vous devez ajouter une gem spécifique à votre bundle (`bundle add xxx`) * Vous devez ajouter un attribut à User (`bin/rails g migration addSecurePasswordToUsers password_digest:string`) - le nom de l'attribut vient de la documentation * Vous pouvez maintenant appeler `has_secure_password` dans `user.rb` * Modifiez les seeds pour créer un utilisateur `root` ayant comme mot de passe `admin123` ## Connexion On va permettre aux utilisateurs de s'authentifier dans notre application. Pour ça, on vous fourni la vue de l'écran de connexion : ```erb

<% if @error_message.present? %>

Oups! <%= @error_message %>

<% end %> <%= form_with url: {action: :create}, class: "text-center" do |form| %>

Merci de vous connecter

<%= form.text_field :username, class:"form-control", placeholder:"Identifiant", value: params[:username] %> Identifiant

<%= form.text_field :password, class:"form-control", placeholder:"Mot de passe", value: params[:password] %> Mot de passe

<%= form.submit "Connexion", class: "w-100 btn btn-lg btn-primary mt-2", data: { turbo: "false" }%> <% end %>

``` * Créez ou générez un controlleur `UserSessions` avec deux actions : `new` et `create`, et les routes correspondantes. * L'action `new` affichera le formulaire, c'est pour cette action que vous utiliserez la vue fournie ci-dessus. * Configurez la route pour brancher cet écran de connexion à l'url `http://localhost:3000/login` * Coder l'action `create` qui : * Cherche l'utilisateur (`User`) correspondant à l'`username` reçu en param. * Vérifie que le mot de passe reçu en param est correct. * Si oui : * Met l'utilisateur en session * Redirige vers le leaderboard : `redirect_to controller: :leaderboard, action: :index` * Si non, rend la vue `new` pour afficher de nouveau le formulaire : `render :new` * La vue peut même afficher un message d'erreur si vous définnissez le bon attribut dans l'action ### Protégez l'application * Modifier le leaderboard pour brider son accès aux utilisateurs connectés : * Si un utilisateur est connecté, le laisser accéder à la page * Sinon redirigez le vers le formulaire de login. (indice: `UserSessions#new`) * Modifier les contrôleurs d'API pour brider leurs accès aux utilisateurs présents en base de données, en forçant l'envoi de l'username et mot de passe en basic auth : * Ajouter un contrôleur APIController (pour l'instant vide) qui hérite de ApplicationController et dont les CreaturesController et CombatsController hériteront. * Ajouter une before action qui vérifie l'authentification sur l'APIController. Si le client n'est pas authentifié, retourner une 403 (comme la 404).