Nous faisons beaucoup de tutoriels sur les rails. Concernant la "session" traitée au chapitre 8, j'ai cette fois écrit un article que je voudrais organiser pour ma propre compréhension. Étant donné que je suis débutant, je vous serais reconnaissant de bien vouloir signaler toute erreur dans les commentaires.
Dans cette communication, la communication entre le navigateur et le serveur est indépendante pour chaque aller-retour. Les informations précédentes ne peuvent pas être héritées.
Cependant, vous vous demandez peut-être quand vous entendez cette histoire. Si toutes les communications HTML sont indépendantes, par exemple sur un site d'achat, Lorsque vous mettez l'article que vous souhaitez acheter dans le panier, les informations ne sont pas reportées, donc Le panier doit être vide lors de la transition des pages.
Donc, ** Le mécanisme de session est de rendre la communication HTML sans état "avec état". ** **
Dans cette communication, des informations sont ajoutées à la communication entre le navigateur et le serveur pour échanger des informations. Il est possible de transformer tout cet échange en une série d'actions.
Dans l'exemple ci-dessus, sur le site où vous vous êtes connecté en tant que membre, vous pouvez accéder à différentes pages tout en conservant les informations du membre. C'est pratique car vous pouvez mettre de plus en plus de choses dans le panier sur le site d'achat.
La "communication avec état" en HTML consiste en un mécanisme appelé session.
Référence: session communication
Comment les sessions
Les sessions ne gèrent pas toujours les cookies, mais ils sont certainement couramment utilisés. Rails utilise également des cookies en standard, nous allons donc accepter les cookies ici.
** ① Premier accès ** Le côté navigateur accède au côté serveur. Le côté serveur envoie les informations d'identification du navigateur (par exemple, les informations de connexion) incluses dans l'en-tête HTTP. Le navigateur enregistre ces informations (ce sont les informations du cookie)
** ② Accès après cela ** Le côté navigateur inclut les informations de cookie enregistrées dans l'en-tête HTTP et les envoie au côté serveur. Sur la base de ces informations, le côté serveur détermine qui y a accédé.
De cette manière, le cookie est l'information détenue du côté du navigateur, et en l'envoyant avec l'identifiant de session, le côté serveur peut comprendre "quel type de contenu avez-vous échangé?" Je vais. À propos, le contenu de la session elle-même est détenu par le serveur Web et l'ID de session dans le cookie est l'ID pour l'appel.
La session n'est que temporaire et est essentiellement supprimée lorsque le navigateur est fermé.
| espace de rangement | La description |
|---|---|
| ActionDispatch::Session::CookieStore: | Enregistrer toutes les sessions dans un cookie sur le navigateur côté client |
| ActionDispatch::Session::CacheStore: | Enregistrer les données dans le cache Rails |
| ActionDispatch::Session::ActiveRecordStore: | Enregistrer dans la base de données à l'aide de l'enregistrement actif(activerecord-session_Besoin d'un bijou de magasin) |
| ActionDispatch::Session::MemCacheStore: | Stocker les données dans un cluster Memcached(Cette implémentation est ancienne, vous devriez donc envisager CacheStore) |
Comme expliqué précédemment, l'ID de session est essentiellement stocké dans un cookie et transmis au serveur,
Pour le CookieStore utilisé par défaut, les ** informations de session elles-mêmes sont enregistrées du côté des cookies. ** **
Le CookieStore présente les ** avantages ** suivants. ・ Très léger ・ Un ensemble a été préparé pour l'utilisation de la session avec l'application Web. -Les données du cookie reçoivent une signature cryptée pour empêcher la falsification, et le cookie lui-même est également crypté, de sorte que le contenu ne peut pas être lu par d'autres (le cookie falsifié est rejeté par Rails).
Cependant, il existe également les ** inconvénients ** suivants. ・ La limite supérieure des cookies est de 4 Ko -Depuis que le cookie est enregistré côté client (navigateur), le contenu du cookie expiré peut rester. ・ Les cookies clients peuvent être copiés sur d'autres ordinateurs ・ Les cookies de session n'expirent pas d'eux-mêmes, ils peuvent donc être réutilisés à des fins d'utilisation abusive.
En gros, je pense qu'il vaut mieux utiliser le Cookie Store recommandé par Rails, J'ai pensé qu'il fallait l'utiliser correctement en fonction de la situation.
Référence: session de guidage des rails
Voici toutes les opérations dans le magasin de cookies qui est utilisé par défaut.
** ・ Créer une session **
session[:user_id] = @user.id
La méthode de session peut être définie avec une valeur de hachage. En paramétrant, un cookie crypté contenant les informations de cette session sera généré.
** ・ Référez-vous à la session **
user = User.find(id: session[:user_id])
Les informations sur la session peuvent être facilement référencées. Lorsque la méthode de session est appelée, les informations du cookie sont décryptées en interne et la valeur peut être obtenue avec session [: symbol].
** - Supprimer la session **
#Tout ce que tu fais est pareil
session[:user_id] = nil
session[:user_id].clear
session.delete(:user_id)
Il est possible de réécrire avec nil ou de supprimer des informations avec clear ou delete.
Quand je l'ai réorganisé, j'ai pu identifier les points que je ne comprenais pas et c'était rafraîchissant. Je souhaite continuer à travailler sur le tutoriel Rails.
Recommended Posts