Discussion :

[Computib]

Bonjour,

je suis débutant en Symfony,
et j'ai généré avec doctrine mon formulaire de base pour remplir ma table client.

Mon problème est que le mot de passe saisie dans le formulaire pour ajouter un client reste en claire dans la BDD...
Je me demande donc comment crypter ce mot de passe avant la sauvegarde dans la base de données.

Il y aurait même tout un traitement sur des données de bases non visibles pour l'utilisateur (qui n'apparaissant pas dans le formulaire d'inscription).

Ma question est donc, comment on chiffre un mot de passe avant sa sauvegarde, et plus globalement où fait-on les traitements sur les champs avant l'envoi du formulaire?

Je précise que tout mes sfValidator sont bon. C'est à l'étape suivante que je bloque. je voulais modifier la fonction processForm() de action.class.php mais je ne veux pas faire n'importe quoi ...

Merci

[Michel Rotta]

J'ai bien envie de me limiter à cela comme réponse, la question a été posée et traitée, à l'identique, par moi, il y a moins d'un moi, dans cette salle.

Je suis bon, j'ai fais la recherche sur "mot de passe" moi même, le sujet "Modifier les données d'un utilisateur avec inputPassword " devrait te donner les deux solutions envisageables, si jamais ton problème était plus spécifique, repasse, je tâcherais d'y trouver une solution, mais pas dans les deux heures

edit du 13/07/2010 à 10:45
Un message qui disparait, mon message amputé d'une phrase, y aurait-t-il des fantômes sur developpez.net ?

[Computib]

Merci pour cette réponse .

J'avais déjà vu ce post mais il ne répond pas à mes attentes.
Ce qu'il me faut, c'est que quand un utilisateur saisie ses informations personnelles moi derrière je crée une série de valeurs par défauts propres à l'utilisateur, comme une date de création de compte.
Beaucoup de données ne sont pas saisies par l'utilisateur mais doivent être créées une seule et unique fois.

Que ce soit le cryptage du mot de passe, la date de création, l'activation du compte qui par defaut vaut zéro, etc...

Si je fait ça dans les setters de mon objet, j'ai bien peur qu'un simple update ("Edit") change ses valeurs... Ou alors peut être que ma vision de symfony n'est pas assez expérimentée pour penser à la bonne solution... Help

[Michel Rotta]

En principe (et c'est un principe qu'il vaut mieux respecter scrupuleusement), l'utilisateur n'a jamais accès aux objets (au sens POO PHP) de l'application !!!

Donc, il n'est pas imaginable qu'un utilisateur puisse modifier ces données personnels à partir d'un objet du modèle, ou alors, la sécurité du site serait tellement corrompue qu'il aurait tout intérêt à attaquer directement la base de données.

Je pense donc que nous pouvons considéré que le site sera construit dans les règles de l'art et que l'utilisateur ne disposera que d'une interface en xhtml ou autre html, sécurisée par les outils intégrés de sécurité de symfony.

Pour ce qui est des valeurs par défaut simple "l'activation du compte qui par défaut vaut zéro" le plus simple est de les indiquer dans le schéma de la base de donnée. Un inconvénient, il n'est pas possible de les modifier sans modifier la structure de la base de donnée, modification lourde.

Pour ce qui est des valeurs par défaut plus élaborées, soit des calculées, soit des valeurs qui proviendraient du fichier de configuration, le mieux est de surcharger la méthode save() de l'objet du modèle, avant l'appel de la méthode parent et d'y mettre le code qui permettra de renseigner et calculer les valeur par défaut, après avoir vérifié que l'objet est bien en création.

Attention cependant, dans cycle normal de création des enregistrement (CRUD de base) de symfony, l'objet record est : créé -> lié à un formulaire -> le formulaire est traité par l'utilisateur -> les données sont vérifiées par les validateurs -> l'enregistrement est enregistré. Les données par défaut vont donc être mise en place après la validation des données et leur traitement par l'utilisateur qui ne pourra donc pas les visualisées.

Il est donc envisageable de positionner ces valeurs par défaut au niveau de la création initial de l'enregistrement, avant qu'il ne soit lié à un formulaire, ce qui implique de le gérer dans le contrôleur, pas idéal, même s'il ne s'agirait que de lancer une méthode crée dans l'objet du modèle.

Ceci reste très théorique.

Il faudrait plus d'information sur ton schéma, sur ce qui doit être initialisé, sur les personas qui vont être amenés à modifier ces données, les visualiser. Sur la manière dont tu comptes y donner accès CRUD simple, admin générateur, simple module qui crée l'enregistrement après.... Avec les informations précédentes, tu devrais pouvoir te faire une idée plus précise et nous pourrons avancer sur le chemin de la solution.

(moins de 2 heures)

[Computib]

C'est bon j'ai trouvé une solution qui m'a l'air de tenir la route
Rappel des principales contraintes:

1) ajout uniquement lors d'un "Create" (inscription d'un nouveau client)
2) ajout de données non saisies par formulaire avec traitement de données

Pour le 1) tout se situe dans le fichier:

Fichier : apps/monAppli/modules/client/actions/actions.class.php

On modifie l'appel à la fonction processForm(...) par processFormCreate(...) dans la fonction ExecuteCreate(...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public function executeCreate(sfWebRequest $request)
  {
    $this->forward404Unless($request->isMethod(sfRequest::POST));
 
    $this->form = new ClientForm();
 
    $this->processFormCreate($request, $this->form);
 
    $this->setTemplate('new');
  }

Puis on ajoute la nouvelle fonction qui appelle une autre fonction de la classe client:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
protected function processFormCreate(sfWebRequest $request, sfForm $form)
  {
    $form->bind($request->getParameter($form->getName()), $request->getFiles($form->getName()));
 
 
 
    if ($form->isValid())
    {
      $client = $form->save();//Sauvegarde du formulaire
 
	  $client->intializeDefaultValues();//fonction définie dans la classe client qui initialise les valeurs par défaut
 
	  $client->save();//re-sauvegarde de l'objet Client
 
      $this->redirect('client/edit?idclient='.$client->getIdclient());
    }
  }

Il faut alors définir notre fonction (contrainte n°2) dans la classe client qui sera chargée de créer les valeurs par défaut :

Fichier : lib/model/doctrine/client.class.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
function intializeDefaultValues()
	{
 
		//Cryptage du mot de passe
 
		parent::_set('mdp', sha1($mdp));
 
		//Date de création du compte
		$now = date("Y-m-d");
 
		parent::_set('datecreation', $now);
 
	}

Pour ce qui est du cryptage je n'ai pas tout mis dans ce code, mais il vaut mieux utiliser des "salt"

Merci à mimi68 pour son temps

Je pense respecter la philosophie MCV et de symfony, ceci ne devrait pas poser de problème de sécurité... Mais si quelqu'un a une meilleure solution ou des critiques je suis preneur !

[Michel Rotta]

L'ionconvéniant de cette solution est que le code est lié au form de création, et pas à l'objet du modèle. Donc, si tu crées un enregistrement depuis une autre partie du code, il faudra être très attentif pour ne pas oublier cette partie, qui sera redondante.

Vu le code, je pense que tu peux le mettre en surchargeant la méthode save() du l'objet client.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public function save()
{
    if ( $this->isnew() )
    {
        $client->intializeDefaultValues();
        parent::save();
    }
}

Qui présente l'avantage d'avoir un code rassemblé dans l'objet client et de s'assurer de son exécution, quel que soit le formulaire ou la procédure qui crée un client. De plus il ne fait appel qu'à une écriture dans la base de données.


Au niveau de la modification du mot de passe, je ne comprend pas ton code, qui ne peut pas fonctionner. A priori, je dirais que tu sauvegardes dans un premier temps le mot de passe non codé dans la base, puis ensuite tu récupères celui-ci pour le coder et le ré-enregistrer. Tu as donc, dans une même zone de la table, deux informations qui vont circuler (même brièvement), un mot de passe en claire, puis un mot de passe crypté. S'il y a le moindre problème dans ton code, tu risques de rester avec une base dans un état instable. Je reste convaincu que jamais le mot de passe ne doit être inscrit en clair dans la base de donnée, il doit être codé au niveau de la méthode setPasse() de l'objet client avant la première écriture et jamais ne doit être écrit dans la base.

Mais cela reste un avis personnel.

[Computib]

Oui effectivement je n'y avais pas penser.
Je suis d'accord avec toi. Je vais faire toutes ces modifications.

Merci