J'ai une application Rails 4 où j'utilise le concept d'authentification et cela fonctionne parfaitement. Mon seul problème est qu'il perd la session d'un utilisateur après que je le déploie sur le serveur et que les utilisateurs doivent se connecter à nouveau.
Si je fais juste un redémarrage de Nginx / passager (que j'utilise pour mon application), il ne la perd pas. Quand je déploie mon application, je le perds. Pour le déploiement, je suis également essuyé automatiquement toute la base de données et mon script de déploiement exécute le fichier de graines qu'elle génère également les utilisateurs.
Nous développons actuellement l'application afin que ce type de comportement soit acceptable pour le moment, mais dans le Futur lorsque l'application sera prête, nous ne le ferons pas comme ça (bien sûr!).
C'est donc un problème en raison de la réensemencement ou de vérifier quelque chose d'autre? Je vois que le mot de passe crypté change à chaque fois que j'exécute l'action Wipe Out / Graine, cela a-t-il à faire avec la perte de session utilisateur?
3 Réponses :
Vous ne devez jamais effacer une base de données lors du déploiement. Imaginez que votre application fonctionne et que vous avez des centaines d'utilisateurs. Maintenant, vous apportez des modifications dans le code et effectuez un déploiement. POOF Toutes vos données et utilisateurs sont partis! Certes, ce n'est pas ce que vous voulez.
Deuxièmement, les utilisateurs se sont déconnectés lorsque vous éliminez la base de données pourrait être dû à l'une des raisons suivantes:
Semensez-vous aux utilisateurs avec le même identifiant? Si l'ID utilisateur change lorsque vous re-graines, les utilisateurs doivent être déconnectés
stockez-vous des sessions dans la base de données à l'aide de rails 4 utilise un magasin de cookies crypté par défaut. Assurez-vous que vous ne changez pas En fin de compte, l'essuyage de la base de données est la seule raison pour laquelle vos utilisateurs se sont déconnectés et c'est une mauvaise pratique. Donc, la chose la plus importante à corriger est
config.session_store: actif_record_store au lieu d'utiliser des cookies? Dans ce cas, l'essuyage de la base de données supprimera la table des sessions et déconnectera tous les utilisateurs
config.secret_token lors de la ré-déploiement, au cas où il est chargé de la base de données
Notre application est en cours de développement, quand elle sera en production, nous ne le ferons pas comme ça, nous allons simplement ajouter des migrations (je l'ai écrite dans mon message). Nous changeons / tests trop, il est donc nécessaire que cela soit nécessaire au début de la phase précoce. L'ID de l'utilisateur est spécifiquement défini dans la graine afin que les utilisateurs aient le même identifiant à chaque fois que nous réensions la base de données. Nous ne changeons pas Secret_Token et nous utilisons la valeur par défaut du congé. Pourquoi cela se produit-il donc?
@Johndel Que diriez-vous des deux autres suggestions? Table des sessions et ID utilisateur?
Nous utilisons: cookie_store en tant que session_store (à l'intérieur de l'initialiszer) et les utilisateurs ont les mêmes identifiants avant et après l'essuyage / retrait.
sur rails 4 devrait également vérifier que Secret_Key_Base ne change pas
Si je fais juste un redémarrage de Nginx / passager (que j'utilise pour mon app) il ne la perd pas. Quand je déploie mon application, je le perds. Pour le déploiement, j'essaplie également toute la base de données automatiquement et mon Le script de déploiement exécute le fichier de graines qu'il génère également la Utilisateurs.
Si vous générez de nouveaux utilisateurs, les anciens vont perdre leurs sessions.
En effet, les valeurs des nouveaux utilisateurs seront différentes. Par exemple, ils n'ont peut-être pas besoin d'un ensemble de jetken souviens-toi, ni si la session_id utilise les valeurs de
user.Created_at ouuser.token_generated_at Ils seront différents chaque fois que vous déposez et Recréez votre base de données.
"Si vous génèverez de nouveaux utilisateurs, les anciens vont perdre leurs sessions". Pourquoi? Les sessions ne sont-elles pas stockées dans le navigateur? Je ne les stocke pas dans la base de données.
Une session est spécifique à l'utilisateur. Si vous créez un nouvel utilisateur, il s'agira d'un utilisateur différent, même difficile, l'adresse e-mail pourrait être la même.
Toutes les lignes d'utilisateur sont les mêmes (id, email, etc.). La seule chose qui change dans la base de données est le mot de passe crypté stocké (même si j'utilise le même mot de passe, le Devise le crypte dans une nouvelle chaîne). Pourquoi? Je stocke la session dans Cookie.
La raison de ce comportement est la suivante:
Chaque fois que certains utilisateurs changent de mot de passe, concevez automatiquement des signes_out.
Donc, essentiellement en retenant les données, le mot de passe est recalculé (même si le mot de passe est identique, le nouveau mot de passe crypté est différent de l'ancien). Donc, le congé signera automatiquement l'utilisateur, car il semble que le mot de passe soit modifié (basé sur les différents champs chiffrées_passwords).
J'ai réussi à contourner ce comportement, en configurant spécifiquement le chiffrement_password dans le fichier graines.rb et en contournant la validation.