Bug #23105
cellule json: permettre de faire des requêtes plus complexes
0%
Description
Actuellement une cellule json peut uniquement faire du GET simple.
On pourrait imaginer pourquoi configurer les choses de façon plus costaude, genre- authentification via login / pass
- authentification "oauth2" (pour autant que ça veuille dire qqchose)
- authentification "hawk" Hawk HTTP authorization
- POST, PUT, voire DELETE
L'idée étant que si on a un fournisseur qui nous donne des webservices interrogeables via des méthodes standards, il suffit de les configurer dans la cellule, pas la peine de faire un connecteur ou autre.
Historique
Mis à jour par Thomas Noël il y a environ 6 ans
- Priorité changé de Normal à Bas
Une idée sans doute moins bête est de faire des connecteurs génériques "auth" dans passerelle ; bref.
Mis à jour par Serghei Mihai il y a presque 6 ans
Je suis d'accord avec cette idée.
Ainsi, une cellule json appelerait le connecteur en lui indiquant le webservice à appeler, la méthode HTTP, le protocole de signature ou authentification et les paramètres pour l'effectuer.
Mis à jour par Benjamin Dauvergne il y a presque 6 ans
Pourvu qu'on utilise des choses compatibles avec python-requests1 oui sûr.
1 https://github.com/mozilla-services/requests-hawk (j'ai un peu peur que ce ne soit pas trop maintenu) https://github.com/requests/requests-oauthlib
Mis à jour par Serghei Mihai il y a presque 6 ans
Yep, c'est l'idée.
Pour Hawk, on peut très bien s'en sortir sans requests-hawk, qui repose sur mohawk qui n'est pas trop maintenu non plus.
Mis à jour par Serghei Mihai il y a presque 6 ans
Pour revenir à la dernière idée de ce ticket: ça pourrait être intéressant que les cellules JSON puissent appeler l'url distante en POST, PUT, DELETE.
Mis à jour par Frédéric Péters il y a presque 6 ans
C'est déjà possible, #22255 parle de PATCH uniquement mais le code autorise également les autres verbes HTTP.
Mis à jour par Serghei Mihai il y a presque 6 ans
C'est le cas lors de la soumission du formulaire dans la cellule, mais ça pourrait être utile d'interroger le webservice distant en POST.
Mis à jour par Frédéric Péters il y a presque 6 ans
À part pour implémenter quelque chose comme un suivi des visites, je ne vois pas dans quelle situation on voudrait qu'une visite de page provoque un POST (et je ne trouve aucun scénario où provoquer un PUT ou un DELETE aurait un sens).
Mis à jour par Benjamin Dauvergne il y a presque 6 ans
Il y a des trucs qui font des POST pour des choses qui sont en fait des GET, typiquement Maarch our la récupération d'une liste de courrier se fait via un POST d'un WHERE SQL. Maintenant est-ce que c'est bien dans combo qu'il faudrait traiter ça où s'en tenir à du REST propre dans combo et laisser ce genre de bizarrerie dans passerelle, je n'ai pas d'avis définitif, ça dépend si on veut faire de combo une sorte de portail couteau-suisse utilisable sans nous par quiconque (Strasbourg!!) ou pas; l'autre possibilité ce serait d'avoir un connecteur REST générique dans passerelle (on fait des GET ou des POST avec des paramétère et derrière ça fait un peu ce qu'on veut, dans le style des query csvdatasource).
PS: je pense que le support de multiple mode d'authentification divers et variés pousserait plutôt pour mettre ça dans passerelle.