+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Split] Sessions ou cookies signés ? (/showthread.php?tid=5945)
[Split] Sessions ou cookies signés ? - niahoo - 28-01-2012
(27-01-2012, 11:17 PM)Sephi-Chan a écrit : 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 colonnepersistence_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 ...)
RE: email confirmation d'inscription et envois de mot de passe en clair - Sephi-Chan - 28-01-2012
(28-01-2012, 08:25 PM)niahoo a écrit : 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
RE: email confirmation d'inscription et envois de mot de passe en clair - php_addict - 28-01-2012
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)
RE: email confirmation d'inscription et envois de mot de passe en clair - Sephi-Chan - 29-01-2012
(28-01-2012, 11:05 PM)php_addict a écrit : 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.
RE: email confirmation d'inscription et envois de mot de passe en clair - niahoo - 29-01-2012
ok merci.
Quel genre d'autres données stockes-tu en cookie également ?
RE: email confirmation d'inscription et envois de mot de passe en clair - Angelblade - 29-01-2012
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.
RE: email confirmation d'inscription et envois de mot de passe en clair - archANJS - 29-01-2012
N'y a-t-il pas un hic, côté sécurité, à utiliser les cookies au lieu des sessions?
RE: email confirmation d'inscription et envois de mot de passe en clair - Sephi-Chan - 29-01-2012
(29-01-2012, 09:12 AM)Angelblade a écrit : 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.
(29-01-2012, 03:34 PM)archANJS a écrit : 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 ?
RE: email confirmation d'inscription et envois de mot de passe en clair - archANJS - 29-01-2012
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.
RE: email confirmation d'inscription et envois de mot de passe en clair - Sephi-Chan - 29-01-2012
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.