Produits Entr'ouvert » w.c.s.

(et là je me dis, mettre tout cette config au fond d'actions de workflow, ça me plait de moins en moins...)

Je ne comprends pas. Cela étant une autre option que je vois c'est de maximiser la configuration "par défaut" (i.e. signer l'url, y mettre l'info de l'utilisateur, ajouter des données au json, etc.).

Juste ce que je pensais, mais que j'aurais dû dire ailleurs et autrement : on devrait configurer les appels webservices ailleurs (des objets du paramétrages, genre "Création d'un item dans le panier du portail citoyen", configuré une fois pour toute) ; et y faire référence dans les actions de workflow.

Ceci étant, en attendant, si on maximise la configuration "par défaut", ne pas le faire pour les ws déjà existants.

et ça : « peut-être en ajoutant un champ (de type WidgetDict) "paramètres supplémentaires" (?) », j'ai pas bien compris

Juste ce que je pensais, mais que j'aurais dû dire ailleurs et autrement : on devrait configurer les appels webservices ailleurs (des objets du paramétrages, genre "Création d'un item dans le panier du portail citoyen", configuré une fois pour toute) ; et y faire référence dans les actions de workflow.

Ok; un niveau d'indirection supplémentaire; ça pourrait aller dans un autre ticket.

Ceci étant, en attendant, si on maximise la configuration "par défaut", ne pas le faire pour les ws déjà existants.

Le seul endroit où il y a un POST du formdata, ça doit être le cg14, non ? Ce serait vraiment sensible à l'apparition de clés supplémentaires dans le json transmis ? Et/ou dans l'URL ?

peut-être en ajoutant un champ (de type WidgetDict) "paramètres supplémentaires" (?)

Dans la configuration, avoir un widget permettant d'entrer des clés / valeurs (WidgetDict, comme dans "Règle de correspondance des attributs pour le statut administrateur"), pour avoir :

  Paramètres supplémentaires
   | source_url  |   :  | [form_url]        |
   | amount      |   :  | [form_var_amount] |
   <add new line>

Au lieu d'un request_signature_key je pensais qu'on irait chercher une clé dans le api-secrets de site_options ? c-à-d plutôt demander une "request_signature_orig" et utiliser quelque chose comme:

key = get_publisher().get_site_option(self.request_signature_orig, 'api-secrets')
sign_url(url, key)

C'est peut-être une mauvaise idée, je ne sais pas.

Je préfère ne pas toucher au site-options.cfg ici mais j'ai trop la flemme pour intelligemment en développer les raisons :/ (pas devoir toucher un fichier sur le fs quand on écrit un workflow, éviter une confusion entrant/sortant pour les clés du fichier)

Heu non, mon idée était plutôt : on a déjà des clés dans le site-options, on les utilise. Uniquement en lecture, comme quand on vérifie une signature.

Oui, quand j'écrivais "ne pas toucher au site-options.cfg", je n'imaginais pas avoir wcs écrire dedans, mais qu'on ait à demander à l'auteur du workflow, devant appeler un ws quelconque, d'aller écrire dans le fichier.

Ok. Actuellement je fais utiliser à Victor des ...&apikey=[bidule_key] dans les URL d'appel, ce qui permet d'éviter à Victor de connaitre les clés, et surtout simplifie beaucoup les copies de workflow d'un site à l'autre. C'est ce comportement que je voudrais conserver.

Et ce patch, mais permettre au paramétrage de request_signature_key de contenir une référence, genre [bidule_key] ?

Oui, tout simplement ; bonne idée.

Ack