Projet

Général

Profil

Development #10990

possibilité d'autocomplétion sur une zone texte via une source de données qui ne serait pas du jsonp

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

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
19 mai 2016
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Pour le moment ça fonctionne uniquement quand c'est du jsonp.


Fichiers


Demandes liées

Lié à w.c.s. - Development #15290: signature automatique des appels data_source en JSONP Rejeté07 mars 2017

Actions
Lié à w.c.s. - Development #19271: possibilité de champ select2 pour une liste (peu importe le jsonp)Fermé09 octobre 2017

Actions
Lié à w.c.s. - Development #45230: autocomplétion des champs texte à partir d'une source de données non-jsonpFermé17 juillet 2020

Actions

Historique

#1

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

#2

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 ?

#3

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.

#4

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.

#5

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 ?

#6

Mis à jour par Benjamin Dauvergne il y a plus de 7 ans

Oui ça me va, un md5 du session.id suffirait aussi.

#7

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

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).

#8

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.

#10

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 ?

#11

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.

#12

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é
#13

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é
#14

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.

#15

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é)

#16

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.

#17

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).

#18

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).

#19

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.

#20

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é

Formats disponibles : Atom PDF