Projet

Général

Profil

Development #7858

pre-remplissage depuis la querystring

Ajouté par Thomas Noël il y a presque 9 ans. Mis à jour il y a plus de 8 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
Début:
16 juillet 2015
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Il serait intéressant de pouvoir pré-remplir certains champs depuis des données reçues dans l'URL.

Exemple : https://wcs/form/?session_var_prefecture=44&session_var_type=association

Cela pose des variables session_var_xxx qui peuvent être utilisée dans le pré-remplissage (formule Python).

Effet de bord intéressants: ces variables sont disponibles partout le temps de la session, d'où usage possible de <img src="/header/logopref-[session_var_prefecture].png"/> dans le template.


Fichiers

Révisions associées

Révision d3670315 (diff)
Ajouté par Frédéric Péters il y a plus de 8 ans

misc: create session substitution variables from query string (#7858)

Historique

#1

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

Hmm je suis peut-être trop inquiet mais la possibilité d'écrire n'importe quoi avec n'importe quelle valeur dans la session me gêne un peu,
il faudrait avoir une liste de nom et un validateur pour les données acceptables, genre:

QUERY_STRING_VARS = (('session_var_prefecture', lambda x: x in map(str, range(1, 100))),)

À mettre éventuellement dans site-options.cfg .

#2

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

Si tu penses à des scénarios particuliers, ça m'intéresse, parce que dans une certaine mesure on autorise déjà les usagers à mettre n'importe quoi dans les variables de substitution (vu que s'y retrouvent des données du formulaire, ou du profil). (pas nécessairement dans ce ticket, pour éviter de l'éloigner trop du sujet).

#3

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

Il suffit peut-être d'une iframe dans un site tiers avec un

http://wcs/?session_var_etc={quote on}"><script src="jsmechant.js"><img src="ddd{quote off}
et que session_var_etc soit interpollé dans un tag img comme dit par Thomas sachant que je ne connais pas les garanties d'ezt sur l'interpolation; y-a-t-il échappement des caractères de contrôle en HTML ?

À ouvrir des URLs avec n'importe quel nom et n'importe quelle valeur un DOS semble possible en construisant des sessions de plus en plus grosses.

Mais la sécurité par énumération de cas ça ne me parle pas, je suis plus de l'école preuve formelle et donc je préfère me dire que rien n'est possible à part ce que l'on souhaite faire.

#4

Mis à jour par Thomas Noël il y a presque 9 ans

Sur le sujet de protection contres les variables de substitutions, cf #7860

#5

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

Avec quelque chose comme "query_string_allowed_vars = foo,bar" dans le [options] du site-options.cfg, ça autorise un ?session_var_foo=bla, et ça donne une variable session_var_foo accessible de partout.

Si l'approche apparait ok, j'ajouterai une page dans la doc technique.

#6

Mis à jour par Thomas Noël il y a plus de 8 ans

Ça me parait la bonne piste.

J'ai pensé à un moment que extra_variables devait être d'abord remis à zéro dès que de nouvelles session_var_ sont vues ; mais non, laissons ainsi, c'est plus amusant au niveau des effets de bord possibles.

Je m'étais dit aussi que ça sera bien de supprimer les ?session_var_truc de l'URL en faisant un redirect, mais je vois pas trop comment le faire proprement à tous les coups.. (en fait, j'avais imaginer au départ gérer ces session_var_ uniquement sur l'ouverture d'une page de formulaire, mais avoir un truc plus générique est plus intéressant).

(à voir : est-ce que ça fonctionne bien si l'URL appelée nécessite un login, qui va changer la session une fois que la personne va être logée ?)

#7

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

Voilà avec un ajout de test qui fait un login entre le passage de query string et l'accès au formulaire.

#8

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

Et voilà la gestion du cas où la même variable est passée deux fois dans la query string (ce qui crée automatiquement une liste), dans cette situation, la variable est simplement et totalement ignorée.

#9

Mis à jour par Thomas Noël il y a plus de 8 ans

Je viens de comprendre que c'est le "isinstance(v, str)" qui refuse les doublons... et du coup je viens bien un petit commentaire genre « # isinstance(v, str) impose une seule déclaration, puisque sinon v est une liste » abrégé en anglais comme tu sais toujours bien le faire.

#10

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

J'ai déplacé un peu les choses pour avoir le comportement "s'il y a une session_var_ dans l'url, alors on l'ajoute à la session et on fait une redirection pour nettoyer l'url".

#12

Mis à jour par Thomas Noël il y a plus de 8 ans

Dans la doc :
  • "personnalisée dans un courriel vers l'usager, qui assurera le" -> retirer la virgule avant le qui
  • "L'utilisation de ce fonctionnement doit explicitement être autorisé" -> "Ce fonctionnement doit explicitement être autorisé"

et pour le reste c'est tout bien, ack.

(Pour la conservation après un login, j'avais en tête un retour SAML en POST, faudra voir si ça passe, j'ai pas bien analysé le déroulé... et si ça marche pas, c'est pas très grave).

#13

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

  • Statut changé de En cours à Résolu (à déployer)

Il n'y a rien de particulier fait avec les sessions du côté du login SAML.

commit d367031503846f81b03b75ebe802c3b974e4d8a7
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Mon Aug 17 16:14:32 2015 +0200

    misc: create session substitution variables from query string (#7858)
#14

Mis à jour par Thomas Noël il y a plus de 8 ans

  • Statut changé de Résolu (à déployer) à Fermé
  • Version cible mis à v1.13.3

Formats disponibles : Atom PDF