[sf 1.4.x] Comment surcharger BasesfGuardAuthActions

[mixka13]

Bonsoir,

Je voudrais savoir comment je pourrais surcharger l'action executeSignin de la classe BasesfGuardAuthActions, en effet cette dernière redirige toujours sur la route @homepage, or je voudrais que la redirection soit conditionnelle, et pour cela je ne vois que la surcharge de cette action pour modifier son comportement à ma guise mais je n'y parviens pas.

De plus m'est-il possible d'utiliser une autre table que la table mise en place par le plugin sfGuardDoctrine pour gérer mes utilisateurs ??
Sinon comment puis-je modifier cette derniere pour qu'elle accueille plus d'informations sans modifier le schema.yml du plugin.

Merci de votre aide.

cordialement Mickael

[Michel Rotta]

Tu peux modifier la redirection à l'aide de paramètre et envoyer sur une autre page que home. Cependant cette redirection est statique dans tous les cas.

D'une manière générale, ce qui se trouve dans ton dossier lib/ est prioritaire sur le reste (pour l'autoload). Tu peux donc créer un dossier lib/plugins/sfDoctrineGuardPlugin/... et y mettre une copie du fichier en question, que tu modifiera. Ainsi tu peux avoir le comportement voulu. Par contre, tu te trouves à la merci de n'importe quel mise à jour et risque d'avoir à développer cette partie.

Je pense que la meilleur solution serait de modifier la configuration du plugin (sans le modifier) pour renvoyer sur une action qui n'aurait pour seul objet que de rediriger vers la bonne page. Ainsi, plus de modification du plugin et arrivée dynamique.


Doctrine accepte la surcharge des tables par héritage. C'est parfaitement réalisable avec la table sfGuardUser.

[mixka13]

Je pense que la meilleur solution serait de modifier la configuration du plugin (sans le modifier) pour renvoyer sur une action qui n'aurait pour seul objet que de rediriger vers la bonne page. Ainsi, plus de modification du plugin et arrivée dynamique.

Je ne comprend pas vraiment cette méthode, en tout cas comment la mettre en place.

Quant à la surcharge de ma table, cela s'effectue bien au niveau du schéma YML, la manipulation des objets doctrine restera la même dans symfony ( je veux dire sauvegarde, utilisation des formulaires, etc )

[Michel Rotta]

Lis le fichier readme du plugin.

A la fin du fichier tu vois comment définir deux routes :

Code :

1
2
3
4
5
 
all:
  sf_guard_plugin:
    success_signin_url:      @my_route?param=value # the plugin use the referer as default
    success_signout_url:     module/action         # the plugin use the referer as default

Tu définis la route après le signin :

• soit sur l'action (toujours la même) qui va suivre le signin (affichage d'un écran).
• soit sur l'action (toujours la même) qui va traiter le retour du signin où tu pourras en fonction d'informations qui te sont propre, rediriger vers ce qui te convient.

Maintenant, si tu veux plus d'informations sur comment faire, il faudra expliquer comment tu veux rediriger vers quoi.


Tu as la documentation sur l'héritage ici.
Utilise un héritage de type Column agregation.

[mixka13]

Merci beaucoup pour ton aide rapide et précieuse, j'avais oublié cette hyper-configurabilité de symfony qui permet de tout faire (ou presque )
Je n'aurais donc qu'a créer une route acceptant un ou des paramètres, la placer an paramètre de success_signin_url et ensuite un action spécifique va traiter cette requête pour me rediriger sur un page donnée suivant le contexte.

Pour l'héritage j'avais retrouvé cette page avant ta réponse, et je me pose la question suivante :

Je ne peux pas faire hérité la table sf_guard_user de ma table perso d'utilisateurs car cela reviendrais a modifier le plugin, et l'inverse et inutile puisque cela sera toujours la table inchangée sf_guard_user qui sera utilisée
Il y a un truc qui m'échappe donc sur la méthode (encore une fois )

De plus qu'elle est la différence entre héritance "simple" et Column agregation. (désolé, j'ai un peu de mal a saisir)

[Michel Rotta]

Pour le routage, oui mais. "Mais" parce que tu ne pourras passer d'informations par la route. Il faut donc les passer par un autre système. Probablement des informations dans l'objet myUser qui représente la session.

Dans le cadre d'un héritage simple la table contiens toutes les colonnes crée pour chaque enregistrement et il n'est pas possible de savoir, pour un enregistrement donné de quel classe il dépend.

Dans le cadre d'une colone agrégation, il y a un champ de plus qui est créé et qui permet de savoir la classe de l’enregistrement.

Si tu n'as qu'un héritage, c'est la même chose. J'utilise colunm agregate par habitue probablement.

Je ne vois pas trop le problème entre tes différentes tables. Le principe est de rajouter des champs à la table. Je ne vois pas pourquoi le fait que la table sfGuardUser soit étendue et non pas qu'elle étende puisse changer quelque chose.

[mixka13]

J'ai réussi a appliquer un héritage sur ma table d'utilisateur, non sans mal je dois bien l'avouer car je n'avais pas saisi la teneur de cette méthode.

Néanmoins je reste insatisfait quant à la solution de mon deuxième problème, je vais tâcher d'être clair, et pour se faire, utiliser un exemple :

Quand l'on se rend sur un topic d'un forum de developpez.com et que l'on clique sur "répondre" alors que l'on n'est pas connecté, on nous propose de nous connecter, une fois que c'est chose faite, nous somme automatiquement redirigé vers la page de rédaction de réponse pour le bon topic précédemment visité, sans devoir n'y rendre de nouveau manuellement.


Mon besoin est du même acabit, alors je présume qu'il doit y avoir une méthode propre et "sémantique", malheureusement je n'arrive pas à mettre de doigt dessus.

Merci a toi pour ta patience.

[Michel Rotta]

Il faut, avant d'afficher la boite de connexion, enregistrer dans l'objet session (myUser)(récupéré depuis le contrôleur par getUser() ), dans l'attributHolder (qui est sauvegardé d'instance de session en instance de session) le chemin de redirection.

Une fois l'authentification réussie, tu renvoies sur un contrôleur qui va vérifier si ce paramètre existe et, le cas échéant, faire un redirect vers l'url enregistrée.

[mixka13]

Ok, c'est pourtant logique ma foi, mais je manque d'experience dans l'utilisation de ce très bon framework.
D'autant plus qu'une méthode similaire est abordé dans le tutorial Jobeet pour mettre en place un petit historique de navigation.

Je te remercie pour ton aide des plus précieuse et spontanée.

[mixka13]

Re-bonjour,

Désolé si je n'édite pas le précédente post mais je pose une nouvelle question et un edit ne rendra pas cette action visible.

En faisant une column aggregation de la ma table sf_guard_user je parviens bien a ajouter des champs à cette derniere ( ) par contre il me rajoute une colonne type qui permet d'après la documentation d'indiquer de quelle type est "l'objet" enregistré d'après l'héritage déclaré dans le schema.yml.
Néanmoins comme cette héritage est plus utilisé dans le cadre de l'extension d'un table "immuable" qu'un d'une conception structurel et sémantique je ne sais pas trop qu'elle est la bonne pratique a mettre en oeuvre.

J'ai tout simplement désactiver ce champs en surchargeant le formulaire comme ce-dessous pour cacher cette information a l'utilisateur final :

Code :

1
2
3
4
5
6
7
8
9
10
11
<?php
 
class mysfGuardRegisterForm extends BasesfGuardRegisterForm 
{
	public function configure()
	{
		parent::configure();
 
		unset($this['type']);
	}
}

Le problème est le suivant, quand je tente d'effectuer la sauvegarde de mon formulaire, j'ai le problème suivant

Code :

csr_token : required

Comment faire pour m'en dépêtrer.

De plus que signifie les deux informations keyField et kayValue que l'on peut renseigner dans le cas d'héritage en aggrégation de colonne, et dont l'absence ne change visible rien.

[Michel Rotta]

Tu as bien fais de faire un nouveau message. Si non, la chance de réponse devait friser le zéro absolu.

Le champs type, créé par la propriété keyField prend la valeur keyValue pour les enregistrements créé par l'objet du modèle. Dans le cas d'un héritage simple, ce n'est pas très grave, c'est s'il y a plusieurs enfants que cela entre en jeux, l'exemple d'une table unique pour gérer de multiple paramètres peut être une indication.

Le champ "type" peut parfaitement (doit) être unset.

Le message "csr_token : required" n'a rien a voir avec cette action. Tous les formulaires sont protégés contre une attaque de type CSRF par un token. Celui-ci est généré dans un champ caché et vérifié au retour par un validateur. Le message signifie que dans la réponse binder au form le champ csr_token n'est pas présent. La cause provient généralement d'un problème lié à la génération du template, tu utilises probablement une génération champ par champ dans le template et tu n'as probablement pas généré les champs cachés.