Discussion :

[etoileweb]

J'ai compris vos deux points de vue et je crois que vous avez tous raisons puisqu'après tout, seule une table sera dérivée et cela ne pose aucun problème de confusion dans les enregistrements. Mais en fin de compte j'ai choisi l'aggrégation de colonne et tout semble bien marché.
Seul problème (et le dernier, je l'espère), l'action signin. En fait, les infos s'enregistrent dans les champs ajoutés de sfGuardUser, tandis que ces champs firstname, lastname, email_address et username, qui sont des initiaux de sfGuardUser restent vides. Du coup l'authentification ne marche pas. Je crois que signin va chercher les infos dans ces champs. Je veux le reconfigurer pour lui indiquer les champs corrects, mais impossible de le trouver. Le fichier actions.class.php du module sfGuardAuth présente la classe suivante qui est vide:

Code :

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

1
2
3
class sfGuardAuthActions extends BasesfGuardAuthActions
{
}

Et je n'ai pas pu mettre la main sur ce basesfGuardAuthActions.class.php. Ou puis-je trouver l'action signin ? Suis-je autorisé à la modifier, sinon comment réussir l'authentification dans ces conditions ? Merci.

[bilbonec]

les infos s'enregistrent dans les champs ajoutés de sfGuardUser, tandis que ces champs firstname, lastname, email_address et username, qui sont des initiaux de sfGuardUser restent vides

A partir de quoi ces objets Doctrine sont-ils construits ? Un formulaire ou tes fixtures ?

Pour ce dernier cas, il y a une écriture particulière quand tu écris un fixture d'une classe enfant ; il ressemblera à ça :

Code :

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

1
2
3
4
5
6
7
sfGuardUser:
  monUser1:
    name: blabla
    email: bleble
    MonProfil:
      added_field1: blibli
      added_field2: blublu

EDIT

J'oubliais, pour l'action signin, un Search dans le plugin sfGuard sur executeSignin te donne directement :
- sfDoctrineGuardPlugin > modules > sfGuardAuth > lib > BasesfGuardAuthActions.class.php

[etoileweb]

Les données proviennent du formulaire du module membre.
Merci, j'ai bien retrouvé BasesfGuardAuthActions.class.php, mais franchement, je n'y vois rien à faire pour faire l'authentification. Tu as une idée ? Ou alors, comment faire pour remplir à partir du formulaire membre les champs originelles de sfGuardUser ?

[etoileweb]

C'est bon, j'ai réussi. J'ai fini par rebuild le modèle en renommant pareil les champs de mon modèle membre correspondant à ceux du modèle sfGuardUser. Ainsi pseudo est devenu username, ainsi de suite... Les données s'enregistrent dans le champ approprié de sfGuardUser qui ne les a pas dupliqués. L'authentification se passe sans le moindre problème. La bataille a été longue mais la victoire l'a couronnée.
Sauf que moi je veux l'affiner un peu plus. Lors de l'authentification, je veux vérifier si le membre a été banni par exemple. J'ai beau regarder dans le module sfGuardUser, mais j'ai pas trouver les actions qui commande l'authentification. Où dois-je faire cette configuration ? merci.

[mantex]

Bonjour,

Intéressante cette discussion.

Si résume l' héritage par aggrégation est conseillé en dupliquant les champs présente dans la table mère dans la table fille ?

Dans ce cas peut ton une table plusieurs fois pour pouvoir gérer des profils ?

ex :

sfguardUser -> client
sfguardUser -> assistant ( pouvant crée d ailleurs créer des clients)

[etoileweb]

Si c'est possible, mais dans ton cas précis, je crois qu'il conviendrait mieux que tu crées différents groupes d'utilisateurs (avec les permissions nécessaires) (Exemple: groupe client, groupe assistant) plutôt que de tables dérivées.

En ce qui concerne la duplication de colonnes, c'est ni l'objectif visé ni une obligation. Je l'ai fait juste pour surmonter une difficulté.

[mantex]

Oui c' est que j' essai de faire mais je ne trouve pas de doc pour gérer cela au niveau du code.

Je crois que les permissions sont gérés avec des credentials


Par exemple.

Les consultants une fois loggués, ils ne voit que les clients qui leur ont été attribué par les assistants.

les clients ne voit que leur profil qu ils peuvent modifier.

[Michel Rotta]

@mantex

Dans sfGuard tu as trois entité, les utilisateurs, les groupes et les droits (credential).

Un (ou plusieurs) droit peut être attribué à un (ou plusieurs) utilisateur.
Un (ou plusieurs) droit peut être attribué à un (ou plusieurs) groupe.
Un (ou plusieurs) groupe peut être attribué à un (ou plusieurs) utilisateur.

Les droits d'un utilisateur sont la jonction de ces droits en directe et de ceux de tous le groupes auquel il appartient.

Par contre, pour ton système, il va falloir jouer du hasCredential() au millieu du code.

Pour les commerciaux, j'ai utilisé (dans une situation semblable) un :
->andWhere('c.groupe IN ?', $this->getUser()->getCredentials() )

Pour les clients, c'est plus simple, dans l'executeShow du profil, tu fais un :
$this->forward404until($this->object->getId() <> $this->getUser()->getId() )

On peut même envisager de l'inclure dans le modèle, mais ce n'est pas nécessairement le plus propre.

[mantex]

Pour les clients, c'est plus simple, dans l'executeShow du profil, tu fais un :
$this->forward404until($this->object->getId() <> $this->getUser()->getId() )

On peut même envisager de l'inclure dans le modèle, mais ce n'est pas nécessairement le plus propre.

Oui pour les crendentials j' ai compris le fonctionnement, j' ai ajouter une action l'executeIndex sous le module sf_guard_user dans laquelle je pense tester mes crendentials.


Qu' en penses tu ?

Ps: # récupérer le user courant loggé

$this->getUser()->getGuardUser()->getUsername()

j' ai un peu de mal avec cette syntaxe.

Je n' arrive pas à la récupérer dans ma vue..

[mantex]

L' action à ajouter doivent bien être défini dans cette classe ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class sfGuardUserActions extends autoSfGuardUserActions
{
 
 
public function executeShow()
 
{
 
 
}
 
}

[mantex]

Par contre j' ai une error si j' appel directement la fonction.

Fatal error: Call to undefined function getUsername()

[etoileweb]

Lors de l'authentification, je veux vérifier si le membre a été banni par exemple. J'ai beau regarder dans le module sfGuardUser, mais j'ai pas trouver les actions qui commande l'authentification. Où dois-je faire cette configuration ? merci.

J'ai fini par trouver le bon moyen. Je suis retourné à la doc du plugin et le paragraphe customize sfGuardAuth actions m'a sauvé. Tout marche bien à présent, enfin presque.
Le seul problème, sfDoctrineGuard chiffre le password avant de le stocker, mais je ne sais quelle fonction il utilise pour ca. J'ai tour à tour utilisé md5 et sha1 mais ca me renvoie toujours "mot de passe incorrect". Quelqu'un sait-il quelle fonction permet de crypter le mot de passe entré dans le formulaire pour le faire correspondre avec ce qui est sauvegardé dans la base de donnée ? merci.

[Michel Rotta]

Le mot de passe n'est pas chiffré, il est hashé. La différence est qu'il n'est pas possible de dé-hashé un mot de passe hashé (c'est même volontaire).

Si tu veux vérifier un mot de passe, il y a une méthode intégrée dans sfGuard qui permet de faire cette vérification ->checkPassword('MotDePasse') qui retourne vrai si le mot de passe est celui de l'utilisateur.

Par contre, je ne vois pas trop pourquoi tu souhaiterais vérifier le mot de passe de l'utilisateur en cour de route (sauf, peut-être, pour valider une action intermédiaire), et encore moins, pourquoi tu voudrais de décrypter ?

[etoileweb]

Ouais, effectivement je confonds chiffrage et hashage (ca arrive quand on arrive à l'informatique en autodidacte). Donc c'était un hashage. Au fait, je ne voulais pas décrypter. Ce qui se passe c'est que j'ai créé mon propre module sfGuardAuth ou j'ai essayé de personnaliser l'action d'authentification, notamment pour vérifier que le compte de l'utilisateur a déjà été activé et qu'il n'a pas été banni. C'était donc sur la comparaison entre le mot de passe entré et celui stocké en base de donnée que ça bloquait. Pour faire correspondre les deux moi j'exécutais la fonction md5 sur ce qui est entré dans le formulaire du sign in, en supposant que doctrine a utilisé la même fonction pour stocker le mot de passe à l'inscription. Soit dit en passant, j'ai essayé la méthode checkPassword (enfin, je crois) sans succès. On m'a proposé ici le sfForkedDoctrineApply qui se charge de tout: envoie d'e-mail de confirmation, vérification de l'activation à la connexion, toutes choses que je veux. Pour l'instant, je bloque un peu là-dessus. Merci d'ailleurs d'y avoir répondu ici. Je continue voir.

[Michel Rotta]

Attention, il y a plusieurs choses qui ne se recoupent pas dans ce que tu dis.

Premièrement. Le sfForkedDoctrineApply qui est un bon module ne résoudra pas ton problème de connexion.

Ensuite, sfGuardUser permet d'utiliser plusieurs algorithme de hash en fonction de l'utilisateur, il convient donc d'utiliser le bon. Le mieux reste d'utiliser la méthode checkPassword qui permet de tester le mot de passe et qui marche bien.

Le vrais mieux serait de s'inspirer de l'objet form d'origine BaseGuardFormSignin et de l'étendre comme un form normal, dans ton lib/form sous le nom de sfGuardFormSignin qui prend alors la place de l'original. Il y a un validateur sfGuardValidatorUser qui valide l'utilisateur, je suppose qu'il faudra, lui aussi, le reprendre dans un dossier à toi lib/validator et l'étendre pour y inclure la notion de validité et de bannissement).

Attention aux interaction éventuelles avec sfForkedDoctrineApply.

A mon avis, c'est la méthode la plus propre pour utiliser le plugin sfGuar et une authentification personnalisée.

Si les champs ne sont pas à saisir par l'utilisateur, il n'y a que le sfGuardValidatorUser qui est à modifier.

[etoileweb]

C'est cool, simple et rapide. J'ai fait comme tu as dit et ca a marché sans problème. Je n'ai plus de problème pour vérifier le mot de passe de l'utilisateur. mais une petite précision, l'objet form d'origine est BasesfGuardFormSignin et non BaseGuardFormSignin. Je me suis fourvoyé un peu avant de trouver Merci beaucoup