Stockage des données de session persistantes dans Rails sans affecter l'expiration normale des sessions

Question

Je souhaite stocker des données persistantes pour chaque navigateur (paramètres utilisateur) et ne souhaite pas utiliser de connexion pour utiliser le site. Quel est le moyen bset pour y parvenir?

J'ai examiné deux approches:

1. stockons les informations contenues dans le cookie de session. Le problème avec cette approche est que je dois définir l'heure d'expiration sur le cookie de session, ce qui a pour effet secondaire de ne pas expirer la session de connexion d'un utilisateur lorsque le navigateur se ferme.
2. Stockez les informations dans la BD et stockez une clé de récupération dans un cookie côté client. Je suis préoccupé par les problèmes de performances, car cela nécessiterait des requêtes supplémentaires et éventuellement une désérialisation pour récupérer les données. Il semble que Rails ait temporairement désactivé ActiveRecordStore pour des raisons de performances: http://ryandaigle.com/articles/2007/2/21/what-s-new-in-edge-rails-cookie-based-sessions

Quelle est la méthode recommandée pour cela? Pourquoi ne pas simplement utiliser un cookie sans session?

Answer 1

Vous pouvez spécifier combien de temps il va persister sur le client, etc. Voir http://api.rubyonrails.org/classes/ActionController/Cookies.html

Si vous êtes préoccupé par l'utilisateur de jouer avec les données de cookie, vous pouvez chiffrer les données de cookie en utilisant une technique comme celle-ci (tirée de http://www.neeraj.name/blog/articles/834-how-cookie-stores-session-data-in-rails) :

cookie_data = {:foo => "bar"} 
digest = 'SHA1' 
secret = 'my_encryption_secret' 
data = ActiveSupport::Base64.encode64s(Marshal.dump(cookie_data)) 
digest_value = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::Digest.new(digest), secret, data) 
escaped_data_value = Rack::Utils.escape(data) 
final_output = "#{escaped_data_value}--#{digest_value}" 
cookies[:user_data] = final_output 

et plus tard pour lire les données des cookies:

Marshal.load(ActiveSupport::Base64.decode64(cookies[:user_data])) 

Answer 2

Il a été réellement changé à partir d'un magasin de session basé sur des fichiers à un magasin de session basée sur les cookies - pas de ActiveRecord. Je peux me tromper, mais je crois qu'ActiveRecord était une option viable pour les fermes Web ou les configurations distribuées lorsqu'un magasin basé sur des fichiers était la valeur par défaut. Depuis l'introduction du magasin à base de cookies, le scénario de batterie de serveurs Web est devenu un non-problème car il est stocké côté client. Aujourd'hui ActiveRecord est toujours une option viable où vous voulez stocker une plus grande quantité de données qu'un cookie le permet, quand vous voulez réduire la surcharge des données transmises dans chaque requête (en utilisant ActiveRecord signifie que vous transmettez seulement le session_id), ou si vous voulez une configuration de session centralisée.

Je trouve qu'en employant un magasin de session d'ActiveRecord, la vitesse n'est pas un facteur pour moi. Dans une session basée sur des cookies, vous limitez généralement ce que vous stockez dans vos variables de session, de sorte qu'ils ont tendance à être des jetons utilisés pour rechercher des données dans la base de données. Si les données n'ont pas besoin d'être conservées au-delà de la session, il est alors possible de stocker l'objet dans la session plutôt que simplement un jeton, car vous allez quand même toucher la base de données pour les enregistrements associés. Si l'objet que vous souhaitez récupérer implique une opération de récupération coûteuse et que vous en avez besoin pendant la durée de la session, il peut être judicieux de stocker cet objet dans la session plutôt que simplement un jeton. est d'abord établi.

Les cookies sont excellents, mais n'oubliez pas qu'un utilisateur peut les supprimer quand ils le veulent, cryptés ou non. Avec l'augmentation des problèmes de confidentialité et de nombreux plugins disponibles pour les navigateurs qui bloquent les cookies de manière conditionnelle, et un logiciel qui nettoie les cookies, vous pouvez peser le pour et le contre de l'utilisation de cookies par rapport à une session soutenue par db. @joshsz fait un bon point sur l'utilisation d'un cookie sans session pour la persistance des données au-delà de la session. Rappelez-vous qu'une session a une durée de vie limitée.