authlogic current_user tracking

Question

J'utilise authlogic pour l'authentification et un trombone pour gérer les pièces jointes des images de profil de l'utilisateur.

J'utilise la méthode suivante pour obtenir le current_user

def current_user_session 
     return @current_user_session if defined? 
(@current_user_session) 
     @current_user_session = UserSession.find 
    end 

def current_user 
     return @current_user if defined?(@current_user) 
     @current_user = current_user_session && 
current_user_session.record 
    end 

et le rappel after_save suivant pour régénérer l'image de profil si l'image a changé.

after_save do |user| 
     if user.image_changed? 
      Delayed::Job.enqueue ImageJob.new(user.id) 
     end 
    end 

La méthode current_user émet un appel et UserSession.find En regardant les documents, il semble UserSession.tries pour connecter l'utilisateur dans, ce qui se traduit par une mise à jour à certains domaines (updated_at, jeton, etc., mais pas l'image de profil), ce qui entraîne une sauvegarde de l'enregistrement de l'utilisateur, ce qui dans mon cas se traduit par l'envoi de rappels after_save . Cette sauvegarde après rappel vérifie si a été un changement à l'image de profil de l'utilisateur, ce qui consomme inutilement du temps.

Maintenant, c'est très bien si l'utilisateur est en effet tente de profil de mise à jour, mais depuis que je l'utilise current_user dans de nombreux endroits différents dans mon application, ce rappel est se faisant virer (et son un cher appel), sans raison .

Je comprends que ce n'est pas exactement question authlogic, mais est-il de toute façon je peut éviter cela, à savoir soit pas mettre à jour l'enregistrement de l'utilisateur ou Différencier en quelque sorte entre ce qui est une mise à jour de profil et ce qui est une mise à jour résultant de cette UserSession.find connexion?

Merci

Voici la solution qui a fonctionné basée sur la suggestion de bjg.

before_save: check_what_changed

def check_what_changed si self.changed.sort == [ "last_request_at", "perishable_token"] = true self.skip_profile_update return true autre self.skip_profile_update = false retour vrai fin fin

Mise à jour # 2 Je retire ce que cela ne fonctionne pas, mais ce n'est pas vraiment un problème avec t sa solution, pour une raison quelconque, paperclip tente de sauvegarder les pièces jointes avant même le rappel after_save. Ceci est probablement un problème de paperclip, aucune idée ..

Answer 1

Dans un rappel before_save, vous pouvez différencier entre un réel changement de profil et les changements liés Authlogic (last_request_at et updated_at attributs) en utilisant les rails intégrés dans des objets sales installation de suivi. Quelque chose le long de ces lignes

attr_accessor :skip_profile_update 

before_save do |model| 
    model.skip_profile_update = (model.changed.sort == ['last_request_at', 'updated_at']) 
end 

after_save do |model| 
    unless model.skip_profile_update 
    # etc 
    end 
end 

Answer 2

je un problème avec la solution de bjg parce que parfois je ne reçois que « last_request_at » et non « updated_at » et ainsi skip_profile_update serait faux.

Je l'ai changé pour ceci qui est une liste blanche des champs qui DEVRAIT déclencher l'after_save, plutôt que la méthode blacklist.Il pourrait être facilement changé à la liste noire en changeant le array comparison method. J'ai également trouvé nécessaire d'inclure tous les «vrais» parce que je recevais ces erreurs redoutables "enregistrement ActiveRecord non enregistré" autrement.

attr_accessor :record_activity 

before_save do |user| 
    user.record_activity = (user.changed & ['email', 'birthday', 'zip', 'gender']).present? 
    true 
    end 

    after_update do |user| 
    if user.record_activity 
    user.send(:record_update_activity) 
    true 
    end 
    true 
    end