Development #10990
possibilité d'autocomplétion sur une zone texte via une source de données qui ne serait pas du jsonp
0%
Description
Pour le moment ça fonctionne uniquement quand c'est du jsonp.
Fichiers
Demandes liées
Historique
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Fichier 0001-misc-add-a-jsonp-endpoint-for-datasources-use-it-for.patch 0001-misc-add-a-jsonp-endpoint-for-datasources-use-it-for.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
Est-ce qu'il n'y a pas un risque au niveau sécurité de créer un proxy ouvert vers une API qui elle est protégée ?
Mis à jour par Frédéric Péters il y a plus de 7 ans
Genre on aurait un formulaire avec un champ type "Liste des établissements" mais ce formulaire ne serait pas accessible, et via cette nouvelle API quelqu'un pourrait malgré tout découvrir le contenu de la liste "Liste des établissements" ? Je me suis posé la question et j'ai considéré que ça n'était pas gênant. (on autorise l'accès à /api/form/xxx/schema à tout le monde)
Quand j'y réfléchissait, j'avais imaginé que ça pourrait être /api/forms/<formdef_slug>/datasources/<field_id>/ avec vérification de la possibilité pour l'usager d'accéder au formdef, mais ça amène des complications sur les champs de l'action "afficher un formulaire", sur l'action d'édition, etc.
Mais si on imagine un risque suffisant, je peux retourner vers cette idée.
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
Si tu prends l'exemple d'une source non critique, bien sûr, le proxy ne l'est pas plus :) Je dis juste qu'il ne sera pas évident pour les utilisateurs de w.c.s. de comprendre qu'en créant une datasource nommée ils créent automatiquement un proxy ouvert vers cette source.
Mis à jour par Frédéric Péters il y a plus de 7 ans
Mais je n'ai pas d'exemple de source critique.
Cela étant, pour se protéger sans pour autant tomber dans les difficultés de ces appels pouvant venir de multiples sources, j'imaginerais le dispositif suivant, inclure dans l'url un jeton, lié à la session.
token = Token() token.session_id = get_session().id token.store() kwargs['url'] = root_url = get_publisher().get_root_url() + 'api/datasources/%s/' % self.data_source.get('type') + '?token=%s' % token.id
Et lors de l'appel à l'URL :
token_id = get_request().form.get('token') if Token.get(token_id).session_id != get_session().id: raise ...
Ça me semble satisfaire le besoin de sécu. Tu en penses quoi ?
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
Oui ça me va, un md5 du session.id suffirait aussi.
Mis à jour par Frédéric Péters il y a plus de 7 ans
- Fichier 0001-misc-add-a-jsonp-endpoint-for-datasources-use-it-for.patch 0001-misc-add-a-jsonp-endpoint-for-datasources-use-it-for.patch ajouté
Le md5 de l'id de session il permettrait un accès à toutes les sources de données, je préfère un jeton dédié.
J'inclus le jeton dans le path de l'URL par facilité pour le cas de la redirection vers la source jsonp (pas besoin de décomposer la query string pour en sortir le jeton avant de faire le redirect).
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
Mouais ben md5(self.datasource.slug + session_id)
alors, enfin bon j'aime pas trop stocker quand on peut s'en passer.
Mis à jour par Frédéric Péters il y a plus de 7 ans
Mis à jour par Benjamin Dauvergne il y a plus de 7 ans
Il y a un rapport avec ce ticket du dernier bout du patch sur wcs/qommon/forms.py ?
Mis à jour par Frédéric Péters il y a plus de 7 ans
De loin, on se trouvait avec un attribut "url" posé sur l'élément <input/> quand il y avait de l'autocomplétion.
Mis à jour par Frédéric Péters il y a environ 7 ans
- Lié à Development #15290: signature automatique des appels data_source en JSONP ajouté
Mis à jour par Frédéric Péters il y a plus de 6 ans
- Lié à Development #19271: possibilité de champ select2 pour une liste (peu importe le jsonp) ajouté
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de En cours à Nouveau
- Patch proposed changé de Oui à Non
Mettons que plus rien n'est proposé vu que ça ne s'applique vraisemblablement pas.
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Sujet changé de source de données sur zone texte → autocomplétion à possibilité d'autocomplétion sur une zone texte via une source de données qui ne serait pas du jsonp
(tentative de reformulation du sujet pour mentionner jsonp pour être plus facilement retrouvé)
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
À la relecture du code il me semble qu'il y a un trou de sécurité, les accès sont validés par la connaissance du slug de la datasource et du hash de ce slug et d'un session_id, n'importe lequel. Tout utilisateur connecté est en mesure de calculer ce hash. Or certaines datasource ne seront visibles que d'utilisateurs ayant accès à certains formulaires (genre une datasource de la liste des agents de la commune, des fiches du RSU, etc..), toute signature doit partir d'au moins une information inconnue de l'utilisateur (le session_id ça ne marche pas), genre settings.SECRET_KEY
, comme ça on est sûr que c'est une URL générée par l'application. Il faudrait aussi un timestamp pour ne pas laisser ouvert ces accès pour toujours, et donc le plus simple ce serait de réutiliser le système de signature qu'on a déjà plutôt que d'en inventer un nouveau.
Mis à jour par Frédéric Péters il y a environ 5 ans
À la relecture du code
Il n'y a pas de code à relire. (cf commentaire numéro 14).
Mis à jour par Benjamin Dauvergne il y a environ 5 ans
Donc à la non relecture du code, je pense qu'il faudrait quand même faire comme je dis (que ce soit du json ou du jsonp) de toute façon, ça reste une indication pour celui qui réaliserait ce code (ne pas faire de hash d'un truc avec le session_id, bad idea).
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Nouveau à Fermé
- Planning mis à Non
Ça a été fait dans #45230.
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Lié à Development #45230: autocomplétion des champs texte à partir d'une source de données non-jsonp ajouté