Discussion :

[littleman]

J'ai rapidement et sans trop de considérations mis en place le système suivant :

un plugin agissant en routeShutDown vérifie avec hasIdentity() si l'utilisateur est authentifié. Si ce n'est pas le cas, on modifie la requête pour exécuter le couple controller/action correspondant au login (directement avec $request->setControllerName() ...).

Le controller/action chargé du login affiche un formulaire pour la saisie du nom d'utilisateur et du mot de passe et si le formulaire a été posté vérifie en base la validité des identifiants.

Le tout semble fonctionner correctement jusque là. Que pensez-vous notamment de l'utilisation du plugin en routeShutDown ?

Je souhaite maintenant améliorer mon processus afin qu'il réponde (si possible) à la problématique suivante et assez fréquente: je suis sur la page qui permet de modifier un article et quand je clique sur le bouton submit je suis redirigé vers le formulaire d'authentification, ma session ayant été détruite par le serveur. Je doit alors en général retourner sur la page et de plus ressaisir mes modifications.

Voilà comment je tente de résoudre ce problème : dans mon plugin chargé de modifier la requête au profit du contrôleur d'authentification je sauvegarde (avant modification) l'objet de requête dans le registre. Le contrôleur d'authentification va retrouver cette requête dans le registre, la sérialise et met le tout dans un champ caché du formulaire. l'utilisateur clique sur le submit, il est authentifié et on peut récupérer la requête initiale en déserialisant le fameux champ caché. J'aimerai alors modifier la requête en la remplaçant carrément par celle que j'ai obtenue par déserialisation et la marquer comme non dispatchée. Or je ne vois pas vraiment comment faire.

Des idées ? (ou commentaires bien entendu)

[oliviercuyp]

Salut littleman,

J'ai plus ou moin le même procédé sur mon projet.
Le routeShutdown, c'est une bonne idée.

Par contre je ne comprends pas pourquoi tu sérializes tout l'objet request ...
Tu pourrais juste sauver le l'url en faisant:

Code :

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

Zend_Registry::set('urlback', $request->getRequestUri());

Une fois le login réussi, pour rediriger l'utilisateur sur l'urlback, il te suffira de faire dans ton controller d'authentification :

Code :

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

1
2
3
4
5
6
7
8
9
public function loginAction {
$request = $this->getRequest();
...
if($request->isPost() && $form->isValid($request->getPost())) {
...
$urlback = $form->getValue('urlback');
$this->_redirect($urlback);
}
}

PS : Pour ma part, je sauve d'office l'url courante dans la session. Je ne suis pas sur que ce soit la meilleure solution... C'est juste que j'aime pas les champs hidden.

[littleman]

oliviercuyp,

Merci pour ta réponse.
Je sérialise tout l'objet request pour essayer de conserver tout ce qui pourrai être passé en POST, j'ai pas vérifié que cela fasse partie de l'objet requête mais j'imagine que oui. Sur développez.net on est souvent obligé de se reconnecter après avoir rédigé une réponse et le post est quand même pris en compte. Je pense qu'un système semblable est mis en place.
Si je me contente de redirigé c'est quand même pas mal mais je perd les données éventuellement saisies.

[oliviercuyp]

littleman,

Dans ce cas, il est sans doute mieux de stocker ces infos dans la session.
Pour 2 raisons:

1. Tu as pas un champ hidden hyper rempli et tout moche
2. Ca te permet de faire ton redirect tranquil puisque tout est en session

Comme cela ça devrait marcher ...

[oliviercuyp]

En gros, si le type est pas loggé, tu gardes son post dans un session_namespace() dédié à cela.
Après le redirect, quand tu reviens sur le submit du formulaire en question aulieu de juste tester le isPost(), tu testes aussi si tu as qqch dans la session_namespace()... et là tu continue la validation de données envoyées.
Et le tour est joué

[littleman]

En fait mon plus gros pb n'est pas vraiment de savoir si je vais utiliser des sessions ou des champs cachée mais plutôt de savoir comment je peux "restaurer" le contexte de la requête initiale surtout au niveau des données POST.
Avec mon système j'arrive à récupérer le triplé module/controller/action initiaux et à dispatcher dessus une fois le login effectuée mais je ne suis pas sûr de pouvoir le faire pour ce qui a été posté.

[oliviercuyp]

littleman,

Disons juste que l'approche où tu mets un object sérialisé dans un champ hidden est une super mauvaise idée au niveau sécurité.

Par exemple, quelqu'un pourrait facilement serialisé un autre object que ta request et forgé un post qui va être interpréter et executé sur ton serveur.
Je te laisse imaginer tout ce qui peu arriver. De plus tu n'as aucun moyen de valider ton object serialisé avec les validators pour empêcher ce type d'attaque ...

Donc en gros, ton approche n'est pas vraiment web et il est fortement conseiller de ne pas mettre du code qui doit être executé dans les POST.
Fais le avec la session, tu cours beaucoup moins de risques...

Voilà, j'espère que tu es plus éclairé maintenant

A+,
Olivier