Projet

Général

Profil

Development #41

Les formulaires quixote ne marchent pas avec les URLs paramétrés

Ajouté par Benjamin Dauvergne il y a presque 14 ans. Mis à jour il y a presque 6 ans.

Statut:
Rejeté
Priorité:
Bas
Assigné à:
-
Version cible:
-
Début:
21 mai 2010
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Planning:

Description

Pour le voir il suffit d'aller sur une page contenant un formulaire avec des champs requis et d'ajouter un paramètre quelconque à l'URL. Un message d'erreur va apparaitre à coté du champ, bien qu'on ait pas soumis le formulaire.

Le problème vient de l'implémentation de HttpRequest et de Form dans quixote. Le premier ne sépare pas les paramètres transmis via le POST des paramètres transmis via l'URL comme PHP peut le faire par exemple avec la variable _POST et la variable _GET, il met tout dans le dictionnaire request.form.

Ensuite comme l'implémentation de base de la méthode _parse dans la class Widget ne vérifie pas que la requête courante est bien un POST mais juste que request.form a une valeur positive on arrive au problème soulevé.

Je pense qu'il serait nécessaire de rajouter à qommon.http_request.HttpRequest deux nouveaux champs .get et .post qui contiendraient les paramètres pour l'URL et pour le POST url-encodé respectivement.

Deuxièmement il faut que Form notifie les widgets qui lui sont ajoutés de sa qualité de formulaire POST, et que les widgets utilisent les paramètres soit .post ou .get en conséquence.

Le besoin vient des problèmes esthétiques que posent le fait de rajouter un paramètre returnURL à une page contenant un formulaire qui a des champs requis.

Historique

#1

Mis à jour par Frédéric Péters il y a presque 14 ans

Ça m'a l'air de déconstruire beaucoup, pour un bénéfice réduit; le returnURL évoqué, il y a bien moyen de le mettre dans un <input type="hidden"/> du formulaire, non ?

#2

Mis à jour par Benjamin Dauvergne il y a presque 14 ans

Imaginons une page /update_info d'un hypothétique IdP qu'on appelerait par exemple authentic. J'aimerai bien qu'une application extérieure par exemple un portail web, puisse rediriger vers cette page mais que la page /update_info sache elle revenir au portail. Il y a deux techniques le referer ou un paramètre d'URL comme 'returnURL'. Le referer ne marchant pas tout le temps il faut au minimum implémenter les deux comme ça c'est bien carré.

Le problème c'est que vu que /update_info contient un formulaire qui contient potentiellement des champs requis, ça va afficher des erreurs 'champs obligatoires' pour rien.

Le fait de rajouter un <input type="hidden" name="returnURL"/> ne fixera pas le problème, on aura toujours l'erreur.

En attendant sur la page de login d'authentic j'ai enlevé de caractère requis des champs username et password, de toute façon on s'en doute, et c'est validé après.

Et oui ça touche à plein de trucs et non c'est pas pour demain; ça peut même être remonté upstream je pense.

#3

Mis à jour par Frédéric Péters il y a presque 14 ans

Oui, tu auras l'erreur, mais tu peux aussi faire un get_request().form = {} pour très facilement l'éliminer.

#4

Mis à jour par Frédéric Péters il y a plus de 13 ans

  • Priorité changé de Normal à Bas
#5

Mis à jour par Thomas Noël il y a environ 12 ans

  • Statut changé de Nouveau à 9
#6

Mis à jour par Benjamin Dauvergne il y a presque 6 ans

  • Statut changé de 9 à Rejeté

Formats disponibles : Atom PDF