Project

General

Profile

Development #7858

pre-remplissage depuis la querystring

Added by Thomas Noël over 7 years ago. Updated over 7 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
Start date:
16 July 2015
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
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.


Files

Associated revisions

Revision d3670315 (diff)
Added by Frédéric Péters over 7 years ago

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

History

#1

Updated by Benjamin Dauvergne over 7 years ago

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

Updated by Frédéric Péters over 7 years ago

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

Updated by Benjamin Dauvergne over 7 years ago

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

Updated by Thomas Noël over 7 years ago

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

#5

Updated by Frédéric Péters over 7 years ago

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

Updated by Thomas Noël over 7 years ago

Ç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

Updated by Frédéric Péters over 7 years ago

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

#8

Updated by Frédéric Péters over 7 years ago

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

Updated by Thomas Noël over 7 years ago

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

Updated by Frédéric Péters over 7 years ago

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

Updated by Thomas Noël over 7 years ago

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

Updated by Frédéric Péters over 7 years ago

  • Status changed from En cours to 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

Updated by Thomas Noël over 7 years ago

  • Status changed from Résolu (à déployer) to Fermé
  • Target version set to v1.13.3

Also available in: Atom PDF