[sf 1.4.x] Champs formulaire password

[mantex]

Dans un form d' un des modules de backend hérité de sfguardUser, le mot de passe hashé est directement rappelé quand j' edite l' utilisateur.

Trés bien me dirait vous ?

Le hic, c' est que cette chaine est à nouveau soumis dans le formulaire même si je ne modifie pas ce champs.

Conséquence : cette chaine devient le nouveau mot de passe et un nouveau hash est généré en base.

J' ai même testé de desactivé le champs dans configure(), le champs est quand même soumis avec une valeur NULL évidemment.

J' aimerai conserver le comportement de sguard qui en cas d' édition d' un user, m' affiche les champs mot de passe vide. Si je modifie pas ces champs dans le formulaire, il n' est pas modifié en base. Propre quoi !

J' espère avoir été assez clair.


Merci d' avance.

[Michel Rotta]

Tu as modifié quoi ?

[mantex]

rien justement.

J' ai juste surchargé la fonction processForm, par ce que j' avais besoin d' envoyer un e-mail quand un nouveau user était crée.

Par contre dans mon formulaire je n' ai qu' un seul champs password (pas de champs confirmation).

C' est celui ci qui récupère la valeur qui est en base quand j' édite le user.
Ce n' est pas le cas dans le sfguardUserForm.

[Michel Rotta]

Tu as forcément un form et un traitement différent de celui de sfGuard. Suffisamment pour qu'on ne puisse s'en inspirer.

Il faudrait le code du contrôleur et des méthodes qui vont avec ainsi que le code du form et, éventuellement, celui du template, mais, en principe, il ne devrait y avoir aucun traitement là.

[mantex]

Ben j' utilise les form auto généré du backend (CRUD), je suis sur un modèle hérité (par agrégation) de sfguardUser.


J'ai donc les champs propres a sfguarduser (id, username, password, email) qui sont complétés par celui de mon modèle modèle (adresse, code postale) .

Les templates sont donc auto-générés de la même manière que pour sfguard.

Si je te mets le code auto généré, je pense que cela t' aide bcp.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
<?php use_helper('I18N', 'Date') ?>
<?php include_partial('consultant/assets') ?>
 
<div id="sf_admin_container">
  <h1><?php echo __('Edition d\'un consultant', array(), 'messages') ?></h1>
 
  <?php include_partial('consultant/flashes') ?>
 
  <div id="sf_admin_header">
    <?php include_partial('consultant/form_header', array('consultant' => $consultant, 'form' => $form, 'configuration' => $configuration)) ?>
  </div>
 
  <div id="sf_admin_content">
    <?php include_partial('consultant/form', array('consultant' => $consultant, 'form' => $form, 'configuration' => $configuration, 'helper' => $helper)) ?>
  </div>
 
  <div id="sf_admin_footer">
    <?php include_partial('consultant/form_footer', array('consultant' => $consultant, 'form' => $form, 'configuration' => $configuration)) ?>
  </div>
</div>

[Michel Rotta]

Si tu relis ce que j'ai posté juste avant, je t'expliquais que le code qui m'intéressait le moins était le template. Par contre, le form et le contrôleur, eux sont beaucoup plus intéressant.

Tu n'as posté que le template Un dicton dit, aide toi et DVP t'aidera...

Dans ce type de configuration, que je ne peux que supposer, le mieux est de modifier ton form, de désactiver le champs standard password et d'en créé un autre non requis, avec son validateur, dont le nom ne correspond pas.

Dans le modèle tu vas modifier et créer un get et un set pour le nom champ de nouveau nom que tu as créé. Le get retournera un string vide systématiquement, le set va prendre la valeur et la mettre a jour dans le champ password si elle n'est pas vide en utilisant la méthode _set('password', $valeur).

Le résultat te donne un form avec un champ password vide. Si tu le laisse vide, rien ne se passe. Si tu le rempli, il est utilisé comme mot de passe. Si un mot de passe est saisi, mais que le form est ré affiché pour une autre raison, le mot de passe saisi reste dans la zone.

[mantex]

Dans mon contrôleur je n' ai aucune fonction qui est utilisée pour les action backend. sauf la fonction processForm() dans laquel j' ai ajouté l' appel à une fonction qui envoie un e-mail.


La ou j' ai du mal, pk les formulaires fonctionnent comme sfguarduser dans tous mes modules hérités sauf la gestion du mot de passe.

Alors que ce champs est justement hérités..

[Michel Rotta]

Je n'ai pas suffisamment d'information pour pouvoir répondre. Et je n'ai pas été livré de la boule de cristal que j'avais commandée !

Ce que je sais, c'est que si tu veux le comportement que tu décris, il faut en passer par ce que j'ai expliqué ci-dessus.

Et tu parles d'héritage, mais je ne suis même pas sur de ce que tu fais hériter, ni de ce que tu appels héritage.

Il faut plus d'information pour avoir, peut-être, une chance de comprendre.

[mantex]

Héritage par agrégation

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
Consultant:
  actAs: { Timestampable ~ }
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
    keyField: type
    keyValue: CONSULTANT
  columns:
   function:     type: string(255)
 
Customer:
  actAs: { Timestampable ~ }
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
    keyField: type
    keyValue: CUSTOMER
  columns:
   consultant_id:  type: integer(8)
   company:       type: string(255) 
   function:      type: string(255)
   address1:      type: string(255)
   postcode:      type: string(255)
   city:          type: string(100)
   tel:           type: string(30)
   mobile:        type: string(30)
  relations:
    Consultant:
      #local: consultant_id
      #foreign: id
      #foreignType: one
     # foreignAlias: customers 
    Contributor:
      local: id
      foreign: id
      foreignType: one
      foreignAlias: contributor

Avec un module backend pour les modules consultant et customer.

[Michel Rotta]

Dans ton modèle, tu as une relation entre Customer et Contributor qui ne me semble pas correctement définie. A mon avis, cela ne peut interférer avec le problème lié au mots de passes, mais pourrait être à l'origine d'un future problème. Le local et foreign pointent tous deux sur des champs Id, hors, en principe, le champ Id est auto incrémenté. Le foreignAlias a pour nom contributor, soit le nom de la table sur laquel il sera défini, ce qui ne sera pas simple pour retrouver les customers d'un contributor en utilisant une méthode getContributor()... Il devrait être "foreignAlias: Cutomer" avec ou sans "s" suivant le nombre de Customer d'un contributor. Le type de liaison n'est pas précis non plus, soit c'est une liaison 1-N et il ne faut pas utiliser foreignType, soit c'est une 1-1 et il faut utiliser "type" et "foreignType".

Ca c'était pour les choses simples.

Pour ton problème, tu dois avoir deux objets générés par ce schéma, un CustomerForm et un ConsultantForm, les deux héritant du form de sfGuardUser. Y as-tu modifié du code ? Si oui, quoi.

Quant tu me dis que tu as un "module backend" tu entends quoi par là ? Pour moi, un module backend est un module qui tourne sur une application appelée 'backend', mais il n'a rien de particulier. Je suppose que par là tu veux dire un module d'administration.

Tu dis que, sur le module où le mot de passe ne passe pas tu as modifié une partie du code. Où ? Si c'est un module d'administration il va perdre une partie de sa capacité à s'auto généré, en as-tu tenu compte ? A priori il s'agit de la création d'un nouveau Customer pour envoyer un courriel, n'aurais-tu pas intérêt à modifier le modèle pour que, lors de la sauvegarde (en fait juste avant), il vérifie si c'est une création et, si oui, envoie le courriel. Ceci permetrait d'éviter de toucher au code d'un module d'admin ?

[mantex]

Oui en fait dans l' application backend j' y ai toutes mes modules de l' appli. J'ai donc mes propres templates qui affiche le traitement de mes actions du même module.

Dans le même temps, j'ai des admin génerator pour chaque module que j' appel avec une route crée par l' admin generator.

SI je résume pour un module, j'ai la partie dev perso qui est sous

apps/backend/modules/NOMDUMODULES/actions/action.php
apps/backend/modules/NOMDUMODULES/templates/*success.php

et une autre gérée (action CRUD) par l' admin générator que j' appel avec dans avec l' url :
mondomaine/backend.php/nomdumodule

Pour répondre à ta question Michel, je ne savais pas que le module backend perdait une partie de ses capacités lorsqu' il est hérité.

Dans mon cas n' est tellement l' histoire du mail qui est envoyé mais la mise à jour systématique de l' enregistrement du user même si on ne touche a aucun champs lorsqu' on l" édite.

En particulier le mot de passe crypté qui est rappelé en clair dans le champs du formulaire et qui est malheureusement chiffré à nouveau avant d' être sauvegardé en base.

C' est comme si on avait saisie un nouveau mot de passe avec la chaine cryptée de l' ancien.

Conséquence l' utilisateur ne peux plus se logguer avec son ancien mot de passe.

j' aimerai simplement ne pas récupérer le mot de passe chiffré quand j' appel la fonction edit.

Ya t -il moyen de faire cela dans la méthode configure() ?

[Michel Rotta]

Si tu relis plus haut, c'est expliqué. Et, vu que tu ne touches pas à la partie générée, cela devrait marcher.

Pour tes modules, j'ai un peu de mal à comprendre comment tu fais cohabiter dans un même module un Admin généré et un classique. Perso, je préfère faire deux modules indépendants.

[mantex]

Envoyé par Michel Rotta

Dans le modèle tu vas modifier et créer un get et un set pour le nom champ de nouveau nom que tu as créé. Le get retournera un string vide systématiquement, le set va prendre la valeur et la mettre a jour dans le champ password si elle n'est pas vide en utilisant la méthode _set('password', $valeur).

Le résultat te donne un form avec un champ password vide. Si tu le laisse vide, rien ne se passe. Si tu le rempli, il est utilisé comme mot de passe. Si un mot de passe est saisi, mais que le form est ré affiché pour une autre raison, le mot de passe saisi reste dans la zone.

Oui désolé mais je ne vois pas comment faire cela dans le modèle.

Le champs mot de passe est celui du modèle hérité , il faut que je crée un nouveau champs dans mes modèles hérités , je vais me retrouver avec 2 champs mot de passe.?

[Michel Rotta]

Pas un nouveau champ, juste les méthodes pour y accéder.

Elles feront toujours référence au champ d'origine. Par contre, le get du mot de passe, pour cet objet, retournera un vide et le set vérifiera qu'il ne le soit pas, vide.

[mantex]

ok sur le principe mais ou l' implémenter.

Comme c ' un admin générator sous /lib/form/doctrine/ConsultantForm.php ?

[Michel Rotta]

Il s'agit de modifier le modèle, donc sur lib/model/doctrine/Consultant.class.php

Ou sur la table parent, vu que, dans mes souvenirs "Consultant" est une table héritée. A toi de voir. Peut-être sur "Consultant" dans un premier temps, vu que le problème n'est que là, puis essayer de migrer sur la tables parent, au cas où ? Mais avec précautions et une bonne vielle série de test derrière.

[mantex]

Envoyé par Michel Rotta

Dans ton modèle, tu as une relation entre Customer et Contributor qui ne me semble pas correctement définie. A mon avis, cela ne peut interférer avec le problème lié au mots de passes, mais pourrait être à l'origine d'un future problème. Le local et foreign pointent tous deux sur des champs Id, hors, en principe, le champ Id est auto incrémenté. Le foreignAlias a pour nom contributor, soit le nom de la table sur laquel il sera défini, ce qui ne sera pas simple pour retrouver les customers d'un contributor en utilisant une méthode getContributor()... Il devrait être "foreignAlias: Cutomer" avec ou sans "s" suivant le nombre de Customer d'un contributor. Le type de liaison n'est pas précis non plus, soit c'est une liaison 1-N et il ne faut pas utiliser foreignType, soit c'est une 1-1 et il faut utiliser "type" et "foreignType".

C 'est l' inverse 1 client a plusieurs contributors..

Les relations de ma table contributor devrait donner ceci non ?

Code :

1
2
3
4
5
6
7
 
relations:
   Customer:
      local: customer_id
      foreign: id
      foreignType: many
      foreignAlias: customer

.

[Michel Rotta]

Si tu respectes toutes les conventions (ce qui est presque le cas) la relation peut s'écrire ainsi :

Code :

1
2
3
4
 
relations:
   Customer:
      foreignAlias: contributors

Les trois valeurs sont celles par défaut, inutile de les répéter.
Le "foreignAlias" est le nom de la relation vu de l'autre côté du lien, ici sur l'objet "customer". Pour un $customer on va retrouver les contributeurs par : $customer->contributors(). A noter le "s" à la fin du "contributors" qui, bien que non obligatoire, le lien pourrait s'appeler "toto", permet de se rappeler que cette méthode retourne une collection d'enregistrement "contributor". Alors que la méthode "getCustomer" de l'objet "contributor" ne retoure elle qu'un "customer".

Donc là ton lien sera bien défini et utilisable.

[mantex]

Tu parles bien des relations de la table contributor ? ou customer ?

Si on on est dans la table contributor le Foreignalias sera customer, est contributors si on est dans la table customer ?

Mais ma clé étrangère (customer_id) se trouve dans la table contributor, ce n' est donc pas la peine de le mettre dans la table customer ?

[Michel Rotta]

Le précédent post parle de relations définies sur l'entité contributor. Et quant on est sur cette table, le foreignAlias pour les relations sera généralement contributors.

Si non, dans ton entité customer du définirais un lien appelé getCustomer() et qui retournerait la liste des contributors. Pas top.

Relation avec tous les paramètres et leur explication

Code YAML :

1
2
3
4
5
6
7
8
9
10
11
12
 
Contributor:
  ...
  relations:
    Customer:                           # Nom de la liaison depuis l'entité contributor 
                                              # (et non de la class par défaut)
      class: Customer                 # nom de la classe a mettre en relation (défaut)
      local: customer_id              # Clef local (valeur par défault) 
      foreign: id                          # Clef sur l'entité Customer (valeur par défault)
      type: many                         # côté contributor n enregistrement (défaut)
      foreignType: one                  # côté customer 1 enregistrement (default)
      foreignAlias: contributors      # nom de la relation côté customer