Maintenant que nous avons terminé le chapitre 8 du didacticiel Rails, je vais publier sur Session en tant que sortie.
Le protocole qui sous-tend Internet, «HTTP», est «sans état». Puisqu'il n'y a littéralement aucun "état", chaque "requête HTTP" n'hérite pas des informations de la requête précédente. Il est facile à comprendre en regardant l'exemple suivant.
"Exemple avec état" Client: Bonjour Greffier: Bienvenue. Bienvenue chez XX Burger Client: je voudrais un ensemble de hamburgers Greffier: Que souhaitez-vous pour le menu latéral? Client: avec des pommes de terre Greffier: Qu'aimeriez-vous boire? Client: Chez Ginger Ale Greffier: Que diriez-vous de faire une boisson taille L pour +50 yens? Client: M va bien Greffier: Voulez-vous vraiment faire cela? Client: Oui Greffier: je suis intelligent
"Exemple sans état" Client: Bonjour Greffier: Bienvenue. Bienvenue chez XX Burger Client: je voudrais un ensemble de hamburgers Greffier: Que souhaitez-vous pour le menu latéral? Client: Veuillez me donner un ensemble de hamburgers avec des pommes de terre Greffier: Qu'aimeriez-vous boire? Client: Veuillez me donner un ensemble de hamburgers avec pommes de terre et soda au gingembre Greffier: Que diriez-vous de faire une boisson taille L pour +50 yens? Client: Veuillez me donner un ensemble de hamburgers avec pommes de terre et soda au gingembre (M) Greffier: Voulez-vous vraiment faire cela? Client: Veuillez me donner un ensemble de hamburgers avec pommes de terre et soda au gingembre (M). c'est tout Greffier: je suis intelligent
Dans l'exemple «avec état», le commis (serveur) se souvient de l'état de la commande du client (client) (il hérite des informations précédentes). C'est ce qu'on appelle l'état de l'application ou l'état de session.
D'autre part, vous pouvez voir que apatride ne se souvient pas du statut de la commande (il ne reporte pas les informations précédentes). Cela peut poser un problème s'il est "apatride". C'est à ce moment que vous utilisez des fonctionnalités telles que «authentification de connexion» et «panier». Si vous oubliez la communication précédente, vous devez effectuer des traitements tels que "authentification de connexion" et "chaque fois que vous voulez plus de produits, remettez tout dans le panier, y compris les produits que vous avez mis dans le passé".
session est une fonction qui se souvient que vous êtes" connecté "afin que vous n'ayez pas à vous reconnecter même si vous changez de page après vous être connecté. En d'autres termes, c'est un mécanisme pour réaliser une communication avec état.
Nous allons sauter la création des contrôleurs et du routage, et commencer par créer le formulaire de connexion.
La plus grande différence entre un formulaire de session et un formulaire d'inscription utilisateur est qu'il n'y a pas de modèle de session pour une session, il n'y a donc pas d'équivalent à une variable d'instance comme @user. Par conséquent, les informations que vous devez transmettre au form_with helper lors de la création d'un nouveau formulaire de session sont légèrement différentes.
form_with(model: @user, local: true)
Rails détermine automatiquement que "l'action du formulaire est un POST vers l'URL / les utilisateurs" simplement en écrivant comme ci-dessus, mais dans le cas d'une session, la portée de la ressource (ici, la session) et son correspondant Vous devez spécifier l'URL spécifiquement.
form_with(url: login_path, scope: :session, local: true)
Notez que les données du formulaire scope :: session => vont dans: session.
Ensuite, le contenu entré dans le formulaire de connexion est reçu par l'action de création du contrôleur de session, et l'utilisateur est trouvé dans la base de données et vérifié.
sessions_controller.rb
def create
user = User.find_by(email: params[:session][:email].downcase)
if user && user.authenticate(params[:session][:password])
#Redirection vers la page d'informations de l'utilisateur après la connexion de l'utilisateur
else
#Créer un message d'erreur
render 'new'
end
end
user = User.find_by(email: params[:session][:email].downcase)
(1) Recevez l'adresse e-mail saisie dans le formulaire de connexion avec les paramètres, récupérez les informations utilisateur de la base de données avec find_by et utilisez la méthode downcase pour garantir une correspondance lorsqu'une adresse e-mail valide est saisie.
if user && user.authenticate(params[:session][:password])
(2) Vérifiez si l'utilisateur est nul et authentifiez-vous avec la «méthode d'authentification».
session[:user_id] = user.id
Lorsque vous exécutez le code ci-dessus, vous pouvez l'enregistrer dans le navigateur avec la méthode de session et accéder au navigateur comme une variable.
#Connectez-vous en tant qu'utilisateur passé
def log_in(user)
session[:user_id] = user.id
end
Si vous êtes connecté, utilisez current_user pour renvoyer des informations sur cet utilisateur. Utilisez également l'instruction if pour réduire le nombre de requêtes de base de données.
#Renvoie l'utilisateur actuellement connecté (le cas échéant)
def current_user
if session[:user_id]
@current_user ||= User.find_by(id: session[:user_id])
end
end
Modifiez ensuite la mise en page lorsque l'utilisateur est connecté et lorsqu'il ne l'est pas. Pour cela, nous avons besoin d'une méthode qui renvoie la valeur logique de savoir si nous sommes connectés ou non, nous allons donc l'implémenter. L'état dans lequel l'utilisateur est connecté signifie que "l'ID utilisateur existe dans la session", c'est-à-dire l'état dans lequel "utilisateur_actuel" n'est pas "nul".
#Renvoie vrai si l'utilisateur est connecté, faux sinon
def logged_in?
!current_user.nil?
end
Utilisez la méthode log_in?, Qui renvoie une valeur logique, pour modifier la disposition comme suit:
<% if logged_in? %>
#Lien pour l'utilisateur connecté
<% else %>
#Lien pour les utilisateurs qui ne sont pas connectés
<% end %>
Pour vous déconnecter, supprimez l'ID utilisateur de la session.
#Déconnectez l'utilisateur actuel
def log_out
session.delete(:user_id)
@current_user = nil
end
Recommended Posts