Gérer la session utilisateur

[Viciousity]

Bonjour à tous et toutes,

Je voulais vous demandez votre avis sur la manière dont vous récupérer les données de votre utilisateur connecté.
Personnellement j'utilise ce système, qu'en pensez-vous ?

Model :

---

def new_token

  self.session_token = new_hash(Time.now, password_salt)

end



def destroy_token

  self.session_token = nil

end



def self.auth_by_token submitted_token

  find_by_session_token(submitted_token)

end

Controller :

---

# Où Params[:user][...] sont les données envoyées en POST (identifiants.)

def current_user

  @current_user ||= User.auth_by_token(cookie.token)

end



def signin

  user = User.auth_by_username(params[:user][:username], params[:user][:password])

  if user

    user.new_token

    current_user, cookie_token = user, user.session_token

  end

end



def signout

  current_user.destroy_token

  current_user, cookie.token = nil, nil

end

Avec cette méthode et l'utilisation de RoR je pense que je suis couvert contre un bon nombre d'attaque standard non ?

[Sephi-Chan]

J'utilisais Authlogic jusque là. Maintenant j'utilise les mécanismes de Rails 3.1. Où tout se joue dans 3 fichiers.

Mon contrôleur principal (dont héritent les autres). Je trouve l'utilisateur courant par son persistence_token.

# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base

  protect_from_forgery

  helper_method :current_user





  private



  def persistence_token

    cookies[:persistence_token]

  end



  def current_user

    @current_user ||= persistence_token && User.find_by_persistence_token(persistence_token)

  end

end

Lors que l'utilisateur se connecte, via le contrôleur sessions :

# app/controllers/sessions_controller.rb

class SessionsController < ApplicationController

  def new

  end



  def create

    @user = User.authenticate(params[:email], params[:password])



    if @user

      cookies.permanent[:persistence_token] = @user.persistence_token

      redirect_to root_path

    else

      render :new

    end

  end



  def destroy

    cookies[:persistence_token] = nil

    redirect_to root_path

  end

end

Et dans le modèle User…

# app/models/user.rb

class User < ActiveRecord::Base

  has_secure_password

  before_save :generate_persistence_token, :if => :password_changed?

  

  def self.authenticate(email, password)

    user = find_by_email(email)

    user && user.authenticate(password)

  end

  

  def generate_persistence_token

    self.persistence_token = ActiveSupport::SecureRandom.hex(32)

  end

end

Et voilà, c'est simple et efficace ! Rails se charge de la moulinette du mot de passe via Bcrypt.

[Viciousity]

Bah sa reste dans la même logique a part que Rails génère pour nous

Faudrait que je migre vers le 3.1 moi

[Sephi-Chan]

Tu vas plus vouloir te passer de l'asset pipeline.

[Viciousity]

Bah j'ai essayé mais j'ai pas été convaincu de l'asset pipeline

Je suis webdesigner a la base et du coup j'aime avoir tout mon css et js en dur directement accessible et lisible :S

Fin le concept cartonne totalement faut juste s'y faire

[niahoo]

perso j'ai deux fonctions de mon framework (nitrogen) donc je sais pas comment c'est géré du coup

wf:user() -> renvoie l'indentifiant utilisateur (qui peut être n'importe quel terme, un integer généralement)

wf:user(User) -> définit l'id de l'utilisateur (donc bon là classique, je cherche le couple id/password dans une base de données et s'il y en a un ça donne l'id


et donc dans chaque page,

case wf:user() of 

    undefined ->  wf:redirect_to_login(Url);

    _             -> %% ok on appelle le contrôleur

end,

...

[Sephi-Chan]

[Viciousity]

J'utillise coffee-script déjà dans rails 3.0.7
Juste pas l'habitude de gérer le dossier assets. Sinon il y a plein de nouveaux trucs que je viens de lire dans la doc 3.1 qui ont l'air pas mal du tout
Je m'y mettrai surement après mon stage a N-Y ^^

Sinon le code en erlang est quand même sacrément obscur :S

[niahoo]

tu ignores vraiment ce qui se passe ou c'est pour faire genre ? Parce que c'est quand même important d'avoir conscience de ce qui se passe

non je ne suis pas encore rentré dans le code du framework pour voir comment c'est géré [edit: je compte bien le faire]

Et qu'est-ce qu'il y a dans l'action de traitement du formulaire de connexion ?

Dans la création du formulaire, on demande la validation (qui se fera via "ajax") du champ email. idem pour le user ou le password.

Code :

wf:wire(submit_login, user_email, #validate { validators=[
        #is_required { text="Requis" },
        #is_email { text="Email non valide" }
    ]}),

Ce code définit la validation à faire pour l'élément qui aura pour id "user_email" lors du clic sur le bouton qui a pour id "submit_login".

Et comment récupères-tu ton objet User (ou ton hash) dans ta base de données (ou autre source de données) depuis cet identifiant ?

un bout de code qui vérifie dans la base l'existence d'un tel login

Code :

login(Email, Password) ->
               PasswordAsMd5 = erlang:md5(Password),
    case db_utils:do (qlc:q ([X#users.username || X <- mnesia:table(users),
              X#users.email == Email,
              X#users.password == PasswordAsMd5]))
    of
        {error, _} -> bad_login ;
    [User|[]] ->
        {ok, User}
    end.

---

Pour désobscurcir :

case wf:user() of 

    undefined ->  wf:redirect_to_login(Url);

    _             -> %% ok on appelle le contrôleur

end,

...

il n'y a pas d'objets en Erlang, mais les fonctions sont groupées par modules, les appels de fonctions sont de la forme module:fonction(arg1, arg2, ...)

switch(wf::user()) {

    case undefined : return wf::redirect_to_login($mon_url);

    default: // appel du controleur

undefined est un atom, comme les trucs en ruby qui s'appellent, je crois, les symbols. ( :undifned )