[Split] Sessions ou cookies signés ?

[niahoo]

De mon côté, j'opte le plus souvent pour un cookie permanent et signé. Et je n'utilise jamais de sessions, seulement des cookies.

Je n'utilise pas non plus l'ID de l'utilisateur mais un persistence token une chaîne aléatoire et unique propre à chaque utilisateur. Ainsi, si je veux forcer la déconnexion d'un utilisateur, je change simplement sa colonne persistence_token, comme ça son cookie ne correspond plus à rien et il est n'est plus connecté.

Peux-tu en dire plus sur ce que tu appelles une « cookie permanent et signé » ?

Si tu n'utilises pas de session, tu ne retiens rien sur l'utilisateur connecté au sein de ton application, tu stockes l'information dans une DB en RAM ? (redis ou autre ...)

[Sephi-Chan]

Peux-tu en dire plus sur ce que tu appelles une « cookie permanent et signé » ?

Si tu n'utilises pas de session, tu ne retiens rien sur l'utilisateur connecté au sein de ton application, tu stockes l'information dans une DB en RAM ? (redis ou autre ...)

Je retiens l'utilisateur connecté grâce au cookie qu'il a. Je ne stock pas du tout d'état côté serveur : ni dans un fichier, ni dans une base, ni en RAM, rien.

Le cookie n'expire jamais et son contenu est chiffré : l'application le déchiffre à la volée quand elle le lit. Du coup son contenu est soit illisible, soit fiable.

class SessionsController < ApplicationController

  def create

    user = User.find_by_email(params[:email])



    if user.authenticate(params[:password])

      # On écrit le cookie permanent en le signant.

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

      redirect_to dashboard_url

    else

      redirect_to root_url, error: t("users.sign_in_failed")

    end

  end





  def destroy

    cookies.delete(:persistence_token)

    redirect_to root_url, notice: t("users.signed_out")

  end

end





class ApplicationController

  def persistence_token

    # On accède au cookie déchiffré (cookies[:persistence_token] aurait retourné le cookie chiffré). 

    cookies.signed[:persistence_token]

  end



  def current_user

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

  end

end

[php_addict]

quel est l'avantage d'un cookie de cet type par rapport au cookie de start_session() en php ? mis à part de pouvoir déconnecter un joueur? (ce qui doit être possible en php avec session_set_save_handler et la gestion des $_SESSION en base de donnée)

[Sephi-Chan]

quel est l'avantage d'un cookie de cet type par rapport au cookie de start_session() en php ? mis à part de pouvoir déconnecter un joueur? (ce qui doit être possible en php avec session_set_save_handler et la gestion des $_SESSION en base de donnée)

La possibilité de déconnecter le joueur n'est pas liée à la non-utilisation de sessions.


Regarde bien ma méthode current_user : elle recherche un utilisateur selon son persistence_token.

Si je change le persistence_token de mon utilisateur, la requête ne trouvera rien et la méthode current_user retournera nil : l'utilisateur ne sera donc plus considéré comme connecté.

Note que la requête n'est effectuée qu'au premier appel de la méthode (au sein d'une même requête) : l'opérateur ||= n'évalue l'expression que si la variable d'instance @current_user est nil ou false. J'utilise cette astuce car j'appelle souvent cette méthode dans mes pages.


Ensuite, l'utilisaton de cookies à la place de sessions est un choix : je préfère utiliser une approche stateless. Je n'ai pas besoin de stocker ça sur le serveur donc… Je ne le fais pas.

De plus, une application stateless tient mieux la charge, même si ça ne me concerne pas pour le moment.

[niahoo]

ok merci.

Quel genre d'autres données stockes-tu en cookie également ?

[Angelblade]

Personnellement j'utilise juste un cookie contenant un id de session. J'aime pas le $_SESSION de php.
Je pense que les autres informations à mettre dans un cookie sont la langue et les petites préférences spécifiques à ton site.

[archANJS]

N'y a-t-il pas un hic, côté sécurité, à utiliser les cookies au lieu des sessions?

[Sephi-Chan]

Personnellement j'utilise juste un cookie contenant un id de session. J'aime pas le $_SESSION de php.
Je pense que les autres informations à mettre dans un cookie sont la langue et les petites préférences spécifiques à ton site.

Je ne comprends pas. Tu stock quoi dans ton cookie ? Car ce que tu décris, c'est le comportement par défaut de PHP : le fameux PHPSESSID qu'il transmet en cookie.

N'y a-t-il pas un hic, côté sécurité, à utiliser les cookies au lieu des sessions?

Quel genre de soucis pourrait-il y avoir ?

[archANJS]

Vols de cookies par exemple. Si j'arrive à voler ton cookie qui t'identifie automatiquement, je peux me connecter sur ton compte sans connaître ton mot de passe.

[Sephi-Chan]

Si tu peux me voler ce cookie, tu peux aussi me voler celui contenant le PHPSESSID et le résultat sera le même.
Il faut également penser à mettre le flag httponly aux cookies, ça permet de limiter les risques de vol via une faille CSRF.