Gestion utilisateurs avec mot de passe crypté

[dorian53]

Bonjour,

Comment s'organiser ?

Sur une gestion d'utilisateurs $oUser en base de données.
Un utilisateur possède un mot de passe crypté via hashage.
Cela signifie que dès qu'un objet utilisateur est instancié (nouvel utilisateur créé ou utilisateur récupéré de la base) son attribut mot de passe est crypté.

On imagine un service addUser($oUser) qui permet de valider puis d'ajouter un utilisateur valide.
Si l'attribut mot de passe est déjà hashé, il n'est alors pas possible de le valider (format, taille) dans cette méthode ?

Comment faire ?
Décomposer la méthode en deux : validUser() et addUser() ?
Cela n'est-il pas mal conçu de proposer une méthode d'ajout qui ne vérifie pas les données injectées ?

Merci

 

[sky]

Salut

Tu doit surement valider les informations soumis par l'utilisateur de toute façon non ?

J'utilise toujours une méthode de validation des informations et une autre pour l'ajout ou encore l'édition.
Ceci te permet de faire les même vérifications lors d'une modification par l'utilisateur de son mot de passe d'ailleurs.

J'appel la méthode de vérification depuis la méthode d'ajout. (ou d'édition)
Faire autrement est dangereux dans le sens ou il ne faudra JAMAIS oublier de valider les informations avant d'utiliser la méthode d'ajout.

Une fois le mot de passe stocké, je ne comprend pas pourquoi ou voudrais vérifier sont format à nouveau.
Mais je comprend peut être mal ta question.

Edit : lorsque je récupère les informations de l'utilisateur, je ne charge pas le mot de passe qui n'est pas une information utile à avoir vu que la validation de la connexion se fait autre part et qu'il est de toute façon crypté / haché. Une donnée de moins à charger

 

[lambi521]

Tu n'as qu'à faire la validation du mot de passe AVANT de le haché. Tu récupères ce que le client tape dans ton champ mot de passe, tu fais tes testes dessus en PHP ou autres, ensuite tu crypte et t'insert en BDD

 

[dorian53]

J'utilise toujours une méthode de validation des informations et une autre pour l'ajout ou encore l'édition.
J'appel la méthode de vérification depuis la méthode d'ajout. (ou d'édition)

Idem et mon problème se situe au niveau de l'objet $oUser que je passe dans addUser($oUser) car le mot de passe est déjà crypté à cette étape, je ne peux plus le vérifier dans cette méthode.

Faire autrement est dangereux dans le sens ou il ne faudra JAMAIS oublier de valider les informations avant d'utiliser la méthode d'ajout.

Je suis d'accord avec ça.

 

[sky]

Je n'ai pas ta classe sous les yeux, mais pourquoi ne pas crypter le mot de passe le plus tard possible ?

 

[AkaHin]

Merci Bien a vous

 

[spout]

Dans CakePHP on crypte le mot de passe dans le callback beforeSave() du modèle, donc dans ton cas, le addUser().

 

[dorian53]

Je n'ai pas ta classe sous les yeux, mais pourquoi ne pas crypter le mot de passe le plus tard possible ?

Dans CakePHP on crypte le mot de passe dans le callback beforeSave() du modèle, donc dans ton cas, le addUser().

Cela signifie que dans la classe User, l'attribut mot de passe à plusieurs états.
Dès fois on manipule l'objet $oUser avec un mot de passe non crypté (cas avant l'ajout), dès fois crypté (cas où l'utilisateur récupéré de la base).
C'est perturbant de ne pas savoir ce qui est manipulé.

 

[sky]

Je t’avoue que je ne me suis jamais posé la question.
Peut être deux variable ?
Au moins pour savoir lequel est crypté ou pas.

Ou sinon la logique du code...

 

[dorian53]

J'imagine plutôt un service annexe pour gérer le cryptage du mot de passe avec validation du mot de passe clair.
Au final, la méthode addUser() traitera bien un objet utilisateur avec un mot de passe crypté, logique dans un sens.

 

[zeb]

Cela signifie que dans la classe User, l'attribut mot de passe à plusieurs états.
Dès fois on manipule l'objet $oUser avec un mot de passe non crypté (cas avant l'ajout), dès fois crypté (cas où l'utilisateur récupéré de la base).
C'est perturbant de ne pas savoir ce qui est manipulé.

Non il n'y a qu'un unique état du mdp et c'est crypté ce qui correspond au magasin de données.
En revanche la méthode addUser($a,$b,...) prend en argument une variable $mdpNonCrypté qui n'a rien a voir avec la classe directement. et c'est d'ailleurs le seul endroit ou doit être manipulé cette donnée.
Pour le reste du système le pass crypté n'a aucune utilisation.

mon problème se situe au niveau de l'objet $oUser que je passe dans addUser($oUser) car le mot de passe est déjà crypté à cette étape, je ne peux plus le vérifier dans cette méthode.

C'est là que tu as un problème de conception, tu ne devrais pas avoir a passer un objet user en paramètre d'une de ses méthodes.
A titre perso pour contourner ce souci temporaire j'ai un constructeur new user(0) (0 correspond a aucun record de la base dans la liste des id) qui me permet d'invoquer la méthode adduser() après instanciation de l'objet. mais cette instanciation est provisoire car je détruit l'objet juste après pour ré-instancier le définitif.
* Adduser() me renvoie l'id nouvellement créé en base
* le constucteur de l'objet prend un id comme paramètre d'instanciation.

 

[Koxin-L.fr]

Bonjour,

Et pourquoi ne pas redemander le pass au moment de la validation de toute modif ? (Ce que font les banque, par exemples)
Je parts évidement du principe que tu nous fait un truc de malade coté sécu pour protéger des data ultra sensibles, parce que sinon, une fois connecté, je ne vois pas l'intérêt de toujours recomparer le pass au moment d'une validation. Il existe les variable de session qui peuvent aider, la comparaison ip, useragent...


Rod

 

[dorian53]

Salut,

C'est là que tu as un problème de conception, tu ne devrais pas avoir a passer un objet user en paramètre d'une de ses méthodes.

Ah bon, et pourquoi ?
J'ai mis en place le fonctionnement évoqué, c'est finalement logique et très simple.
Un objet utilisateur a toujours un mot de passe crypté au format défini.
Pour définir ce mot de passe crypté une méthode est à disposition, elle attend un mot de passe clair avec un format défini.


Désolé Koxin-L, je pense que nous ne parlons pas de la même chose.

 

[Koxin-L.fr]

ok )

 

[zeb]

Ah bon, et pourquoi ?
...
Un objet utilisateur a toujours un mot de passe crypté au format défini.

Bah justement pas dans le cas qui est le tiens (a ce que j'en comprend bien sur). Pour le cas très précis (et pas courant) de création d'un utilisateur il y a ce flou entre "je vais le créer" et "je suis créé" qui fait que l'objet que tu passe en paramètre est bancal (dans addUser($oUser)).
Un utilisateur n'en est un que quand il est enregistré donc créé, avant cette phase c'est un "prospect" (ou tout ce que tu veux) mais c'est pas encore un vrai utilisateur puisque sont mot de passe n'est ni validé ni enregistré.
Le propre d'un objet est de regrouper un ensemble de choses don les propriétés sont toutes existantes et au même format.

Si l'attribut mot de passe est déjà hashé, il n'est alors pas possible de le valider (format, taille) dans cette méthode ?
Comment faire ?
Décomposer la méthode en deux : validUser() et addUser() ?
Cela n'est-il pas mal conçu de proposer une méthode d'ajout qui ne vérifie pas les données injectées ?

Tu peux ensuite ajouter une propriété "mot de passe en attente de validation" a ton objet pour contourner le problème. Ta méthode de validation opérera sur le mdp non crypté et sera en mesure de réinitialiser les propriétés d'un utilisateur déjà créé (le mdp crypté principalement, son id) tout en enregistrant celui ci en base.

Mais je voie tjs pas l'utilité de faire addUser($oUser) dans la mesure ou la méthode peut très bien avoir accès a toutes les propriétés de l'objet qui fait l'objet du traitement.

bref je cerne peut être pas ton problème ...

 

[dorian53]

Ah bon, et pourquoi ?
...
Un objet utilisateur a toujours un mot de passe crypté au format défini.

Bah justement pas dans le cas qui est le tiens (a ce que j'en comprend bien sur). Pour le cas très précis (et pas courant) de création d'un utilisateur il y a ce flou entre "je vais le créer" et "je suis créé" qui fait que l'objet que tu passe en paramètre est bancal (dans addUser($oUser)).
Un utilisateur n'en est un que quand il est enregistré donc créé, avant cette phase c'est un "prospect" (ou tout ce que tu veux) mais c'est pas encore un vrai utilisateur puisque sont mot de passe n'est ni validé ni enregistré.
Le propre d'un objet est de regrouper un ensemble de choses don les propriétés sont toutes existantes et au même format.

On est d'accord, c'est pour cela que mon objet user est toujours instancié avec un mot de passe crypté. Pas de bidouille comme évoqué ci-dessous, lorsque je manipule un objet user aucun doute, le mot de passe existe et est toujours du même format (crypté).

Si l'attribut mot de passe est déjà hashé, il n'est alors pas possible de le valider (format, taille) dans cette méthode ?
Comment faire ?
Décomposer la méthode en deux : validUser() et addUser() ?
Cela n'est-il pas mal conçu de proposer une méthode d'ajout qui ne vérifie pas les données injectées ?

Tu peux ensuite ajouter une propriété "mot de passe en attente de validation" a ton objet pour contourner le problème. Ta méthode de validation opérera sur le mdp non crypté et sera en mesure de réinitialiser les propriétés d'un utilisateur déjà créé (le mdp crypté principalement, son id) tout en enregistrant celui ci en base.

Mais je voie tjs pas l'utilité de faire addUser($oUser) dans la mesure ou la méthode peut très bien avoir accès a toutes les propriétés de l'objet qui fait l'objet du traitement.

bref je cerne peut être pas ton problème ...

L'utilité du addUser($oUser) c'est l'encapsulation des données, il est plus simple de passer un seul objet que n variables, d'utiliser les getters que de manipuler les données manuellement, c'est plus maintenable, etc...

 

[zeb]

addUser() est externe a la classe ?