Cookies et sessions avec CookieStore

Question

Dans Rails 3, quelle est la différence entre le stockage de données dans un cookie et le stockage de données dans une session, avec le magasin de session défini par défaut sur CookieStore ?

par exemple

cookie[:foo] = 'bar'

# MyApp::Application.config.session_store :cookie_store, key: '_myapp_session'
session[:foo] = 'bar'

D'après ce que je sais, les deux sont stockés dans un cookie côté client.

Quand choisiriez-vous d'utiliser l'un plutôt que l'autre ?

Merci.

Answer 1

La principale différence est que lorsque vous utilisez cookie[:foo] = 'bar' l'utilisateur est en mesure de voir la valeur du cookie, à savoir 'bar' . Lorsque vous utilisez session[:foo] = 'bar' la valeur sera chiffrée par les rails et stockée dans le fichier _myapp_session cookie.

Vous utiliseriez le cookie[] lorsque les informations que vous souhaitez stocker ne sont pas liées à la session, par exemple lorsque les utilisateurs sélectionnent la langue préférée.

Vous utiliseriez le session[] lorsque vous souhaitez stocker des informations liées à la session en cours, par exemple le format id de l'utilisateur.

Answer 2

Rails fournit plusieurs mécanismes de stockage pour les hachages de session. Les plus importants sont ActiveRecord::SessionStore y ActionDispatch::Session::CookieStore .

Il existe un certain nombre de stockages de session, c'est-à-dire l'endroit où Rails enregistre le hachage et l'identifiant de la session. La plupart des applications réelles choisissent ActiveRecord::SessionStore (ou l'un de ses dérivés) par rapport au stockage de fichiers pour des raisons de performance et de maintenance. ActiveRecord::SessionStore conserve l'identifiant de session et le hachage dans une table de base de données et enregistre et récupère le hachage à chaque demande.

Rails 2 a introduit un nouveau stockage de session par défaut, CookieStore . CookieStore enregistre le hachage de la session directement dans un cookie côté client. Le serveur récupère le hash de session dans le cookie et élimine le besoin d'un identifiant de session. Cela augmente considérablement la vitesse de l'application, mais il s'agit d'une option de stockage controversée et vous devez réfléchir à ses implications en matière de sécurité :

Les cookies impliquent une limite de taille stricte de 4kB. Cela ne pose pas de problème, car vous ne devriez pas stocker de grandes quantités de données dans une session, comme décrit précédemment. Le stockage de l'identifiant de base de données de l'utilisateur actuel dans une session est généralement acceptable. Le client peut voir tout ce que vous stockez dans une session, car les données sont stockées en texte clair (en fait, elles sont codées en Base64, donc pas cryptées). Donc, bien sûr, vous ne voulez pas stocker de secrets ici. Pour empêcher la falsification du hachage de la session, un condensé est calculé à partir de la session avec un secret côté serveur et inséré à la fin du cookie. Cela signifie que la sécurité de ce stockage dépend de ce secret (et de l'algorithme du condensé, qui est par défaut SHA512, lequel n'a pas encore été compromis). N'utilisez donc pas un secret trivial, c'est-à-dire un mot tiré d'un dictionnaire ou un mot de moins de 30 caractères.