Authentification Rails 8 : le générateur natif pas à pas

AtelierFix gère les réparations, mais pour l’instant n’importe qui connaissant l’adresse peut les consulter, les modifier, les supprimer. Tant que l’application tourne sur le portable de Modou, ça va ; le jour où elle est en ligne, c’est un problème immédiat. Il faut une porte d’entrée : un écran de connexion qui réserve le back-office à Modou et à ses employés. Bonne nouvelle — depuis Rails 8, l’authentification n’est plus une affaire de bibliothèque externe. Un générateur intégré écrit pour vous les modèles, les contrôleurs et les écrans de connexion, en suivant les bonnes pratiques de sécurité. On va s’en servir.

À la fin de ce tutoriel, l’accès à AtelierFix passera par un identifiant et un mot de passe, les mots de passe seront stockés hachés (jamais en clair), et vous saurez protéger ou ouvrir une page au choix.

🎯 Ce que vous allez apprendre

• Générer un système d’authentification complet avec bin/rails generate authentication ;
• Comprendre les modèles User, Session et Current qu’il produit ;
• Créer le premier compte et vous connecter ;
• Protéger l’ensemble du back-office, et ouvrir une page précise au public ;
• Afficher qui est connecté et proposer une déconnexion.

🛠️ Ce que vous allez construire

Une barrière d’authentification devant AtelierFix : un écran de connexion, un stockage sécurisé des mots de passe avec bcrypt, et la règle « pas de session, pas d’accès » appliquée à toute l’application — sauf aux pages que vous décidez explicitement de laisser ouvertes.

Prérequis

• Avoir suivi le tutoriel Créer un CRUD complet avec scaffold : la gestion des réparations fonctionne dans le navigateur.
• ⏱️ Temps estimé : ~40 minutes.

Ce que le générateur met en place

Avant de lancer la commande, posons le vocabulaire. L’authentification de Rails 8 repose sur trois modèles. User représente un compte : une adresse e-mail unique et un password_digest — l’empreinte chiffrée du mot de passe, jamais le mot de passe lui-même. Session représente une connexion ouverte : elle appartient à un utilisateur et mémorise l’adresse IP et le navigateur, pour qu’on puisse révoquer une session précise. Current est un porte-document de requête : il expose Current.user, l’utilisateur connecté, accessible partout dans le code le temps d’une requête.

Le générateur ajoute aussi un concern Authentication branché sur tous les contrôleurs. Deux méthodes y comptent : require_authentication, un before_action qui exige une session valide et redirige vers la page de connexion sinon ; et allow_unauthenticated_access, l’échappatoire qui ouvre une page au public. Retenez ce couple : il commande qui voit quoi.

Étape 1 — Générer l’authentification

Une seule commande pose toute l’infrastructure :

bin/rails generate authentication

Rails crée les modèles User, Session et Current, les contrôleurs de connexion et de réinitialisation de mot de passe, les vues correspondantes, et le concern Authentication. Il ajoute aussi la gem bcrypt au Gemfile (en la décommentant si elle y était déjà) puis lance bundle install : c’est bcrypt qui hache les mots de passe. Comme deux nouvelles tables sont décrites (users et sessions), appliquez les migrations :

bin/rails db:migrate

Regardez le modèle généré app/models/user.rb : il contient has_secure_password. Cette seule ligne, fournie par Rails, ajoute la vérification du mot de passe, exige un champ de confirmation et chiffre l’enregistrement via bcrypt. Vous n’avez aucune logique de hachage à écrire — et c’est tant mieux, car c’est exactement le genre de code qu’il ne faut jamais bricoler soi-même.

Étape 2 — Créer le premier compte

Le générateur n’installe volontairement pas de page d’inscription : sur un outil interne comme AtelierFix, on ne veut pas que le public crée des comptes. On fabrique donc le compte de Modou à la main, en console :

bin/rails console

User.create!(email_address: "modou@atelierfix.sn", password: "atelier2026", password_confirmation: "atelier2026")

Le create! avec point d’exclamation lève une erreur immédiate si quelque chose cloche (mot de passe trop court, e-mail déjà pris) — pratique pour voir tout de suite ce qui ne va pas. En production, choisissez évidemment un mot de passe solide. Quittez la console avec exit.

Étape 3 — Se connecter

Tout est en place. Relancez le serveur et tentez d’ouvrir http://localhost:3000/reparations. Surprise voulue : Rails vous redirige vers l’écran de connexion. C’est require_authentication qui agit — le générateur l’a activé pour toute l’application. Saisissez l’e-mail et le mot de passe de Modou, validez : vous voilà ramené vers la page demandée, désormais accessible.

✅ Point d’étape — Sans session, AtelierFix renvoie systématiquement vers la connexion ; avec un compte valide, l’accès s’ouvre. Si la connexion échoue alors que le mot de passe est bon, vérifiez que la migration a bien été appliquée et que bcrypt est installé (bundle install).

Étape 4 — Ouvrir une page au public

Tout protéger est parfois trop strict. Imaginons qu’AtelierFix affiche une page publique « Suivi de ma réparation » où un client entre un numéro de ticket — celle-là ne doit pas exiger de connexion. La règle se pose au niveau du contrôleur concerné, avec allow_unauthenticated_access :

class SuiviController < ApplicationController
  allow_unauthenticated_access only: %i[ index ]

  def index
    # page publique de suivi
  end
end

L’option only: cible les actions concernées ; le reste du contrôleur, lui, reste protégé. C’est le bon réflexe : on protège par défaut, et on ouvre délibérément les rares pages publiques, plutôt que l’inverse. Une porte qu’on oublie de verrouiller est plus dangereuse qu’une porte qu’on oublie d’ouvrir.

Étape 5 — Afficher l’utilisateur connecté et se déconnecter

Un back-office sérieux montre qui est connecté et offre un bouton de déconnexion. Ces deux éléments vivent dans la mise en page commune, app/views/layouts/application.html.erb, pour apparaître sur toutes les pages. Ajoutez, à l’intérieur du <body>, juste avant <%= yield %> :

<% if Current.user %>
  <p>Connecté : <%= Current.user.email_address %>
     <%= button_to "Se déconnecter", session_path, method: :delete %></p>
<% end %>

Current.user renvoie l’utilisateur de la requête en cours (ou nil sur la page de connexion, d’où le if). Le button_to envoie une requête DELETE vers session_path — la route de destruction de session générée pour vous — ce qui ferme la session et vous renvoie à l’écran de connexion. Rechargez une page protégée : votre e-mail s’affiche, avec le bouton. Cliquez : vous êtes déconnecté, et toute tentative d’accès redemande l’identifiant.

✅ Point d’étape — Vous voyez votre e-mail en haut des pages protégées et pouvez vous déconnecter d’un clic. Le cycle complet connexion → navigation → déconnexion fonctionne. Si session_path est introuvable, vérifiez la ligne resource :session dans config/routes.rb (ajoutée par le générateur).

Comment Rails se souvient que vous êtes connecté

Une question revient toujours : entre deux clics, comment l’application sait-elle que c’est bien Modou, et non un inconnu ? Le web est sans mémoire — chaque requête arrive seule, sans souvenir de la précédente. La réponse tient en deux pièces qui se répondent. Quand vous vous connectez, Rails crée un enregistrement dans la table sessions (lié à votre User, avec votre IP et votre navigateur) et dépose dans votre navigateur un cookie signé contenant l’identifiant de cette session. À chaque requête suivante, le navigateur renvoie ce cookie ; le concern Authentication le lit, retrouve la session correspondante en base via resume_session, et en déduit l’utilisateur — qu’il range dans Current.user.

Ce design a deux vertus concrètes. D’abord, le cookie est signé : un utilisateur ne peut pas le falsifier pour se faire passer pour un autre, car la signature serait invalide. Ensuite, parce que les sessions vivent en base, on peut les révoquer : supprimer la ligne correspondante déconnecte aussitôt l’appareil concerné. C’est ce qui permet, dans une vraie application, un écran « Mes appareils connectés » avec un bouton « Déconnecter ce téléphone » — utile si Modou perd le sien. Vous n’avez rien à coder pour cela aujourd’hui, mais comprendre le mécanisme vous évite de le craindre : l’authentification n’est pas une magie opaque, c’est un cookie signé d’un côté, une ligne en base de l’autre, et une méthode qui relie les deux à chaque requête.

🐞 Pièges fréquents

🌍 Adaptation au contexte ouest-africain

Deux points méritent attention pour un déploiement en Afrique de l’Ouest. D’abord, le mot de passe ne protège rien si la connexion n’est pas chiffrée : exigez le HTTPS en production (Rails l’impose via config.force_ssl = true), ce que le déploiement avec Kamal — vu au tutoriel suivant — fournit gratuitement. Ensuite, la réinitialisation de mot de passe générée par Rails envoie un e-mail : configurez un service d’envoi fiable (un fournisseur transactionnel, ou le SMTP de votre hébergeur) avant de compter dessus, car un e-mail qui n’arrive jamais bloque l’utilisateur dehors. Pour un atelier à équipe réduite, vous pouvez aussi vous passer de cette page au début et réinitialiser un mot de passe en console — simple et sans dépendance.

✅ Récapitulatif

AtelierFix a maintenant une serrure. En une commande, vous avez généré une authentification complète, compris le rôle des modèles User, Session et Current, créé un compte, sécurisé tout le back-office et appris à ouvrir une page au public quand c’est nécessaire. Surtout, les mots de passe sont hachés par bcrypt — vous n’avez écrit aucune ligne de cryptographie, et c’est exactement ce qu’on attend d’un débutant : utiliser des fondations éprouvées plutôt que d’improviser sur un sujet aussi sensible.

🧾 Aide-mémoire

💪 À vous de jouer

Empêchez un utilisateur connecté de voir la liste des réparations d’un autre atelier… ou, plus simple pour commencer : affichez un message de bienvenue personnalisé sur le tableau de bord, du type « Bonjour, modou@atelierfix.sn ».

<!-- app/views/dashboard/index.html.erb -->
<% if Current.user %>
  <p>Bonjour, <%= Current.user.email_address %>.</p>
<% end %>

Tutoriels frères

• Créer un CRUD complet avec scaffold et formulaires — le back-office qu’on vient de protéger.
• Déployer une application Rails avec Kamal sur un VPS — mettre AtelierFix en ligne, en HTTPS.

Pour aller plus loin

• 🔝 Retour au guide principal : Ruby on Rails : le guide complet pour débuter
• Documentation officielle : Securing Rails Applications

FAQ

Pourquoi ne pas utiliser la gem Devise ?
Devise reste excellent et très répandu. Mais pour débuter, le générateur intégré de Rails 8 a un gros avantage : il produit du code que vous lisez et comprenez, dans votre propre application, sans boîte noire. Vous apprenez les mécanismes ; vous pourrez toujours adopter Devise plus tard si vos besoins se complexifient.

Où est la page d’inscription ?
Le générateur n’en crée pas, volontairement : beaucoup d’applications internes n’autorisent pas l’auto-inscription. Si vous en voulez une, il suffit d’ajouter un contrôleur Registrations qui crée un User ; c’est une extension naturelle.

Les mots de passe sont-ils vraiment sécurisés ?
Oui : has_secure_password les hache avec bcrypt, un algorithme conçu pour résister aux attaques par force brute. La base ne contient jamais le mot de passe en clair, seulement son empreinte.

Comment réinitialiser un mot de passe sans e-mail configuré ?
En console : récupérez l’utilisateur et faites user.update!(password: "nouveau", password_confirmation: "nouveau"). Pratique en développement ou pour un dépannage rapide.