Rails de Concevoir - current_user est nul
Pour une raison quelconque, current_user
retourne nil
dans mon modèle-moins contrôleur (Subscriptions
). Je n'ai rien trouvé sur Internet pour justifier ce comportement...
class SubscriptionsController < ApplicationController
def new
...
end
def create
current_user # returns nil
end
end
J'ai une csrf de la balise meta :
<meta content="xxx" name="csrf-token">
Je peux fournir plus de code, mais je ne suis pas sûr de ce qui serait utile.
Mise à JOUR
Donc merci pour les commentaires/réponses, j'ai posé le problème à une seule action : create
.
si j'ajoute @user = current_user
à la new
, je peux témoigner de l'utilisateur actuel de l'e-mail dans mon new
vue. Cependant, dans mon create
contrôleur, current_user
retourne nil
.
J'ai consulté le create
action par le biais d'un formulaire (soumettre).
Avant que le formulaire est soumis, je valider l'entrée et ensuite envoyer une demande à Bande pour obtenir un jeton de la forme. Si il n'y a pas d'erreurs (de la validation et de la bande), j'ai ensuite envoyer le formulaire.
Que cela pourrait être la cause?
Mise à JOUR 2
Dans mon message d'erreur, ma séance de vidage est vide, alors qu'il devrait contient les current_user info...
User
? parce que current_***
prendra le nom du modèle. Ce n' user_signed_in?
retour?Il est défini à false... C'est bizarre, parce que l'utilisateur doit être authentifié pour voir la page
OriginalL'auteur Justin D. | 2013-08-24
Vous devez vous connecter pour publier un commentaire.
Il s'est avéré que la requête AJAX, j'ai été prise de ne pas porter le jeton CSRF. Pour cette raison, les Rails a été tué ma session.
J'ai ajouté
skip_before_filter :verify_authenticity_token
dans monSubscriptionsController
et il est maintenant opérationnel. Il pourrait ne pas être la solution la plus sûre, mais il fonctionne pour l'instant, donc je continue de développer et de revenir sur cette question plus tard.Cela fait quelques mois et je ne me souviens pas exactement. Il est certainement causé par mon appel AJAX...
OriginalL'auteur Justin D.
pour
current_user
fonctionne, vous devez ajouterbefore_filter :authenticate_user!
à votre classe, comme:et la
authenticate_user!
méthode va définir l'utilisateur courant pour vous 🙂Eh bien, oui,
:authenticate_user!
ce qu'il fait est de vérifier pouruser_signed_in?
et si c'est faux, envoyer l'utilisateur vers la page de connexion. Il n'est pas nécessaire pourcurrent_user
être initialisé.Le truc, c'est que l'utilisateur est censés pour être authentifié parce qu'il a accédé à la page. Ainsi, alors que
authenticate_user!
montre le problème, il ne prend pas directement en résout. Très utile pour localiser l'erreur.Le débogage de votre question: tout d'Abord, assurez-vous d'exécuter exactement "créer" de l'action.. d'autre part, il suffit de vérifier si votre session est stable sur toute action: lieu quelque part dans une vue
<%= request.session_options[:id] %>
. Il ne serait pas changer. Donc, si 1 et 2 a été adopté, donc le problème est dans la logique d'application...tous les before_filters deprecated dans Rails 5.0 et sera supprimée dans Rails 5.1. Utilisation before_action au lieu
OriginalL'auteur Vinicius
Notez que lorsque vous créez des formulaires en utilisant les
form_tag
helper, ils ne génèrent pas automatiquement le champ caché qui détient le jeton CSRF d'authentification. J'ai rencontré ce même problème avec un formulaire que j'avais construit à l'aide de laform_tag
qui je préfère parfois utiliser.J'ai résolu le problème en suivant notamment les aides à l'intérieur de la forme:
<%= hidden_field_tag 'authenticity_token', form_authenticity_token %>
C'est essentiellement un manuel façon de générer le champ caché vous avez besoin pour le CSRF choses.
OriginalL'auteur Adam Waselnuk