Je traverse actuellement un tutoriel ROR ( http: // RailStorial.org/Chapters/sign-in-sign-Out#sechsignin_success est la section pertinente) qui semble être assez bonne, bien que j'ai rencontré le problème suivant lors de la tentative de visualisation du site de l'échantillon.
module SessionsHelper
def sign_in(user)
cookies.permanent.signed[:remember_token] = [user.id, user.salt]
current_user = user
end
def sign_out
cookies.delete[:remember_token]
current_user = nil
end
def current_user= (user)
@current_user ||= user_from_remember_token
end
def signed_in?
!current_user.nil?
end
private
def user_from_remember_token
User.authenticate_with_salt(*remember_token)
end
def remember_token
cookies.signed[:remember_token] || [nil, nil]
end
end
4 Réponses :
le nil? La méthode ne va pas vérifier si une variable ou une méthode est définie. Il vérifie uniquement si cela est défini comme un objet nul ou non. Ruby marche la chaîne des ancêtres pour SessionsHelper et détermine enfin que le courant_utilisateur n'est pas défini nulle part (il finira par finir au noyau # méthody_missing), puis jette une erreur. Le moyen le plus rapide de résoudre le problème serait le suivant:
#app/helpers/sessions_helper.rb def current_user @current_user ||= false end
Ou je crois que vous pourriez faire "@Current_user || = user_from_remember_token || false" Si vous souhaitez être plus en ligne avec votre code actuel.
Bien que cela arrête certainement l'erreur, cela retourne constamment de faux. Je suppose qu'il est possible qu'il puisse y avoir un problème avec ma signature de méthodes qui provoquent une consommation actuelle de ne jamais être définie, donc probablement mieux pour que je puisse y jeter un coup d'œil après une bonne nuit de sommeil.
J'ai demandé à un ami et il corrigea mes erreurs. Je pense qu'une grande partie de mon erreur vint de ne pas être complètement familiarisée avec une portée variable dans Ruby et que tout est un objet et que la méthode actuelle_user = (utilisateur) remplace la fonction d'affectation.
La solution de mon ami était de changer La portée de Current_User à une variable instanciée (elle peut donc être utilisée correctement) et modifier la fonction CURENT_USER = (utilisateur) vers une simple fonction get_current_user afin de déterminer si l'utilisateur actuel existe dans le cookie.
Le code final modifié est le suivant: Comme vous pouvez voir la variable dans mon en-tête partiel a également été modifié pour refléter la méthode utilisée dans l'assistant pour obtenir l'utilisateur pour obtenir l'utilisateur . va commencer à lire des guides de base de rubis de base si la prochaine fois que j'entre au-dessus de ma tête, j'ai une idée de l'endroit où commencer de la fixer :)
Une meilleure pratique pour les rails L'autorisation serait de nommer la méthode Current_User au lieu de GET_CURRENT_USER et définissant une méthode Current_User? Cela vérifie si le courant actuel est nul ou non. C'est un modèle très courant.
Y a-t-il une raison particulière pour cela? Ou est-ce, comme la plupart des rails semblent être, juste parce que c'est comme ça que les gens le font? Je peux voir une augmentation de la lisibilité, je me demandais simplement s'il y a une autre raison que je manque.
Ce n'est pas juste une chose de rails. La convention de rubis pour getters and Setters est attribute_name () et attribut_name = (). La capacité d'ajouter? Pour les noms de méthodes était intentionnel afin que les développeurs puissent former des questions cohérentes. Ruby est conçu pour être aussi conversationnel que possible.
Assurez-vous de disposer du code suivant dans la sessionHelper
J'ai couru dans ce même problème et c'était pour la même raison. Vous avez négligé une partie des instructions sur 'Listing 9.16'. Vous étiez censé modifier ceci en ce qui suit. P> def current_user
@current_user ||= user_from_remember_token
end