Produits Entr'ouvert » Passerelle

A noter que :

• ' curl -T ' ne passe pas de nom du fichier (pas de multipart juste du contenu brute)

C'est pas grave, tu reprends le nom du fichier existant ou tu laisses Django se débrouiller avec la mise à jour de csv_file, et si vraiment t'arrives à rien tu mets "api-uploaded-file-<aaaammddhhmmss>.<ext>"

Une remarque en passant : un intérêt à supporter un format {"file": {"base64_content"...}} en plus de l'upload direct (et on peut supporter les deux en se basant sur la condition Content-Type: application/json) c'est que ça permet de gérer ça depuis un formulaire w.c.s. "Mise à jour du référentiel XXXX", qui nous donne un historique des actions.

Ok, ce sera l'occasion d'implémenter le PUT dans passerelle,
et aussi l’authentification basique non, si on veut pousser la simplification au bout ?
(gros ticket en fait)

Nicolas Roche a écrit :

Ok, ce sera l'occasion d'implémenter le PUT dans passerelle,

Il y a déjà un PUT dans le connecteur Greco; mais il y a surtout des soucis pour la doc des schémas et les descriptions quand on déclare plusieurs méthodes sur un même endpoint, voir le commentaire "BUG" dans passerelle/contrib/rsa13/models.py. La seule conséquence c'est qu'il n'est pas évident de faire une API Rest dans le style une ressource/plusieurs méthodes comme on fait avec DRF. Mais là le besoin ne me semble pas être ça.

et aussi l’authentification basique non, si on veut pousser la simplification au bout ?
(gros ticket en fait)

Non apikey est rigoureusement équivalent à HTTP Basic en terme de sécu (c'est un secret partagé en clair) et ça demande aucun boulot, juste mettre ?apikey= dans l'URL (l'inconvénient c'est que l'apikey est visible dans les logs des proxys, je pense qu'on peut continuer à vivre avec, ils voient tout dans l'absolu, mais ne le log que si demandé pour le reste); donc aucun besoin d'HTTP Basic, ça n'a jamais bloqué personne à ma connaissance.

Il y a déjà un PUT dans le connecteur Greco

J'ai un doute sur le fait qu'il fonctionne : il manque le put dans passerelle/views.py::GenericEndpointView
https://dev.entrouvert.org/issues/51983 (il manque juste les 2 lignes, pas tout le patch)

Non apikey est rigoureusement équivalent à HTTP Basic en terme de sécu (c'est un secret partagé en clair)

Merci, je n'avais pas encore compris comment ça fonctionnait.

• retirer l'envoie du nom du fichier (en inventer un) et du nom de la feuille de style
• supporter les 2 formats 'curl -T' et le json avec base 64
• prévoir une permission spéciale perm='can_update_file'

• juste (la mise à jour) le contenu du fichier, qui doit rester exactement au même format.

Nicolas Roche a écrit :

https://dev.entrouvert.org/issues/51983 (il manque juste les 2 lignes, pas tout le patch)

Tu dois avoir raison.

Donc ici :

• retirer l'envoie du nom du fichier (en inventer un) et du nom de la feuille de style

ou conserver le nom du fichier actuel s'il y en a déjà un.

• supporter les 2 formats 'curl -T' et le json avec base 64

Oui je pense que ça ne mange pas de pain de faire ça en se basant sur le content-type quand il vaut "application/json".

• prévoir une permission spéciale perm='can_update_file'

Mais je n'ai pas compris si "qui doit" est quelque-chose que je dois assurer ou juste supposer :

• juste (la mise à jour) le contenu du fichier, qui doit rester exactement au même format.

Je crois que Thomas veut dire ne faire aucun contrôle à part ce que l'on ferait déjà sur un upload sur le backoffice (je ne sais pas si on fait un contrôle sur les colonnes, ou au moins sur leur nombre).

Benjamin Dauvergne a écrit :

Nicolas Roche a écrit :

https://dev.entrouvert.org/issues/51983 (il manque juste les 2 lignes, pas tout le patch)

Tu dois avoir raison.

Ne pars pas dans des sous-sous-tickets : si PUT ne marche pas, alors gère juste POST, basta.

Je crois que Thomas veut dire ne faire aucun contrôle à part ce que l'on ferait déjà sur un upload sur le backoffice

Indeed.

Ne pars pas dans des sous-sous-tickets : si PUT ne marche pas, alors gère juste POST, basta.

si j'ai parlé de ça c'est parce que 'curl -T' fait un PUT.

• supporter les 2 formats 'curl -T' et le json avec base 64

edit:

ou conserver le nom du fichier actuel s'il y en a déjà un.

En fait on n'écrase pas les fichiers mais on les effaces via cron.
Donc si j'ai data.csv, et que je repousse data.csv alors j'aurais en fait data_azAZ567.csv
Et donc il me faudra deviner data.csv depuis data_azAZ567.csv (ok mais c'est du code moche).

aucun contrôle à part ce que l'on ferait déjà sur un upload sur le backoffice

Via le backoffice, on ne peut pas pousser de fichier ODS sans indiquer de nom de feuille.
Ici il faudra donc refuser le chargement d'un ODS si la feuille n'est pas renseignée dans le connecteur,
(ou peut-être si le format CSV,ODS... détecté par le connecteur diffère).

Et donc il me faudra deviner data.csv depuis data_azAZ567.csv (ok mais c'est du code moche).

Non tu inventes rien on s'en tape du nom de fichier.

Et pareil pour le PUT, soit ça marche et ok, soit ça n'existe pas encore dans Passerelle et c'est un autre ticket et le sujet disparait de celui-ci.

Dispersion zéro.

• retirer l'envoie du nom du fichier (en inventer un) et du nom de la feuille de style
• refuser le chargement d'un ODS si la feuille n'est pas renseignée dans le connecteur
• supporter le json json avec base 64

Pour le 2 premiers points je peux aussi négocier ?
(parce que là on retomberait sur mon patch qui le mérite de ne pas ajouter de code spécifique)

• prévoir une permission spéciale perm='can_update_file'

Tu vas dans wcs, tu crées un formulaire avec un champ fichier, tu lui donnes comme identifiant "fichier". Tu crées un workflow, tu associes le workflow au formulaire, dans le workflow tu crées une action "appel webservice". Tu configures cette action pour être un POST et envoyer un paramètre nommé file et avec comme valeur {{form_var_fichier}}.

Tu mets pour cet appel l'URL vers le nouvel endpoint.

Ensuite tu publies le formulaire tu mets un fichier csv dans le champ tu valides la demande.

Par cette action le connecteur dans Passerelle doit désormais être configuré avec ce nouveau fichier.

Frédéric Péters a écrit :

Tu vas dans wcs (...)

Alors je ne sais PAS DU TOUT pourquoi on parle de w.c.s.

Il s'agit ici de permettre à un tiers (un client, un éditeur) de se faire un script à sa façon pour mettre à jour la nuit le csv_file d'un csvdatasource. Zéro usage de wcs.

Et pour moi, on devrait chercher à suivre le même protocole (la même API) que le import-csv des fiches dans wcs. Histoire de ne pas avoir mille doc à écrire, et rester sur un exemple facile avec cURL.

Alors je ne sais PAS DU TOUT pourquoi on parle de w.c.s.

Pour fournir à Nicolas un format à suivre et qu'il soit produit quelque chose qui fonctionne de bout en bout.

Pour oublier ce ticket le côté PUT, qui est le truc utile, mais visiblement nébuleux, et que cette partie arrive derrière, dans un nouveau ticket.

"CSV file" c'est historique, le connecteur parle de "Spreadsheet file" car il gère aussi ods, xlsx, etc. Il faudrait donc modifier les phrases comme "Uploading CSV file is limited to the following API users:" ou "Modify CSV file" et parler de "Spreadsheet file".

'''accept curl -T queries''' : commentaire pas très clair et donc un peu inutile à mon avis, plutôt dire que le payload est le fichier. Ou ne rien dire, le code est assez clair je trouve (et il y a ce ticket en référence git blame)

Utilise plutôt request.content_type tu te fatigueras moins (https://docs.djangoproject.com/fr/2.2/ref/request-response/#django.http.HttpRequest.content_type)

Je ne comprends pas « storage = getattr(self.csv_file, 'storage') » ... pourquoi getattr ?

display_order=-1 : je préférerais que ce endpoint soit plutôt référencé en dernier, et dans un catégorie "Management" (et les autres dans une catégorie "Access")

Nicolas Roche a écrit :

Je ne comprends pas « storage = getattr(self.csv_file, 'storage') » ... pourquoi getattr ?

c'est juste pour pylint

Vu... laisse pleurer pylint, c'est lui qui se trompe.

display_order=-1 : je préférerais que ce endpoint soit plutôt référencé en dernier, et dans un catégorie "Management" (et les autres dans une catégorie "Access")

fait ; j'ai du changer les libellés pour ne pas avoir les ':' en double.

Ok vu... bon, modifie juste le csvdatasource_detail.html pour ajouter ton endpoint en dessous des autres, et hop... un autre ticket un jour "nettoiera" ce connecteur pour le conformer à des endpoints mieux autodocumentés.

Il manque l'i18n dans le html (ie ajouter des {% trans ...)