[SPIP Zone] CVT-Uploads, Formidable et le téléversement de fichiers

Archives Zone
1

je sors d'une épique bataille pour permettre à nos usagers de téléverser des images via un formulaire Formidable.

Quand j'ai découvert que cvt-upload + Formidable = téléversement de fichiers dans un formulaire, je me suis jeté dessus car c'est un besoin discuté depuis longtemps.

Le hic, c'est que seul le téléversement de fichiers non graphiques fonctionnait chez moi. Les PDF, par exemple passaient parfaitement, alors que pour les GIF, JPEG et PNG, rien a faire, toujours les message

"Le fichier « XXXX » n’a pas pu être stocké correctement par le système. Contactez le webmestre."

En déroulant les appels des fonctions, j'ai vu qu'une fois la fonction _verifier() de cvt-upload passée, le fichier temporaire qui était créé entre le téléversement par PHP (dans le répertoire /tmp/) et celui dans le tmp/ du site (ou l'instance) SPIP avait disparu.

Donc quand Formidable essayait de recopier ce fichier à son emplacement de stockage définitif, le fichier manquait et générait cette erreur.

À force de chercher, je me suis rendu compte que le problème venait de l'invocation de la noisette :
cvt-upload/formulaires/inc-cvtupload-fichier.html
et plus précisément du filtre "_image_reduire_base64"

En effet, une fois que le filtre a fait sa conversion en base 64, le fichier original est supprimé car "Ceci permet que la vignette ne soit pas conservée dans local/ et donc évite que la vignette d'une image potentiellement confidentielle soit visible" (documentation de la fonction).

Sauf que là, ça ne fait pas notre affaire.

Du coup je propose ce petit patch en PJ. Si je suis le seul à avoir expérimenté ce problème et que certain.e.s parmi vous l'ont contourné depuis longtemps, je veux bien avoir l'explication de comment ça marchait avant pour vous.

Si vous voulez que je le commit, n'hésitez pas.
--
Camille

cvt-upload.diff (2.08 KB)

2

Salut camille,

On a aussi eu quelques problèmes qui semblent similaires à ce que tu décris (moi et RastaPopoulos).
Ça s’est produit avec des images (pas testé avec d’autres types de fichiers), mais le souci c’est que c’est aléatoire : des fois ça passe, des fois non.

Voilà exactement ce qui se produit :

  1. On valide le formulaire une 1ère fois, ça mouline une dizaine de secondes avec un message «erreur» qui apparaît en haut. Ce n’est pas un message de retour du formulaire, mais une erreur ajax. Et dans l’inspecteur de réseau / POST : erreur 401, «vérifier les droits d’écriture. Si votre navigateur n’est pas redirigé, cliquez ici pour continuer.»

  2. On valide une 2ème fois, et là ça passe.

Il y a eu aussi quelques mails similaires à celui que tu cites : « Le fichier « XXXX » n’a pas pu être stocké correctement etc. »

On va donc tester ton patch pour voir si ça résoud le problème de notre côté.

3

Le 05/10/2018 à 17:44, Charles Razack a écrit :

Salut camille,

On a aussi eu quelques problèmes qui semblent similaires à ce que tu décris (moi et RastaPopoulos).
Ça s'est produit avec des images (pas testé avec d'autres types de fichiers), mais le souci c'est que c'est aléatoire : des fois ça passe, des fois non.

Voilà exactement ce qui se produit :

1) On valide le formulaire une 1ère fois, ça mouline une dizaine de secondes avec un message «erreur» qui apparaît en haut. Ce n'est pas un message de retour du formulaire, mais une erreur ajax. Et dans l'inspecteur de réseau / POST : erreur 401, «vérifier les droits d’écriture. Si votre navigateur n’est pas redirigé, cliquez ici pour continuer.»

2) On valide une 2ème fois, et là ça passe.

Il y a eu aussi quelques mails similaires à celui que tu cites : « Le fichier « XXXX » n’a pas pu être stocké correctement etc. »

On va donc tester ton patch pour voir si ça résoud le problème de notre côté.

Dans des saisies, ou dans formidable ?

--
nicod_

4

Le 05/10/2018 à 15:49, Camille Sauvage a écrit :

je sors d'une épique bataille pour permettre à nos usagers de téléverser des images via un formulaire Formidable.

Quand j'ai découvert que cvt-upload + Formidable = téléversement de fichiers dans un formulaire, je me suis jeté dessus car c'est un besoin discuté depuis longtemps.

Le hic, c'est que seul le téléversement de fichiers non graphiques fonctionnait chez moi. Les PDF, par exemple passaient parfaitement, alors que pour les GIF, JPEG et PNG, rien a faire, toujours les message

"Le fichier « XXXX » n’a pas pu être stocké correctement par le système. Contactez le webmestre."

En déroulant les appels des fonctions, j'ai vu qu'une fois la fonction _verifier() de cvt-upload passée, le fichier temporaire qui était créé entre le téléversement par PHP (dans le répertoire /tmp/) et celui dans le tmp/ du site (ou l'instance) SPIP avait disparu.

Donc quand Formidable essayait de recopier ce fichier à son emplacement de stockage définitif, le fichier manquait et générait cette erreur.

À force de chercher, je me suis rendu compte que le problème venait de l'invocation de la noisette :
cvt-upload/formulaires/inc-cvtupload-fichier.html
et plus précisément du filtre "_image_reduire_base64"

En effet, une fois que le filtre a fait sa conversion en base 64, le fichier original est supprimé car "Ceci permet que la vignette ne soit pas conservée dans local/ et donc évite que la vignette d'une image potentiellement confidentielle soit visible" (documentation de la fonction).

Sauf que là, ça ne fait pas notre affaire.

Du coup je propose ce petit patch en PJ. Si je suis le seul à avoir expérimenté ce problème et que certain.e.s parmi vous l'ont contourné depuis longtemps, je veux bien avoir l'explication de comment ça marchait avant pour vous.

Si vous voulez que je le commit, n'hésitez pas.

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

merci pour ton rapport de bugue. Le patch lui-même n'est à mon avis pas le bon, car il faut simplement s'assurer que l'original soit différent du fichier réduit au sein de la fonction base_64, quelque soit le type de fichier. Le problème peut arriver dès lors que la fonction de compression d'image n'est pas executé, pour une raison y ou y.

Maïeul

5

Le 06/10/2018 à 09:43, Maïeul a écrit :

Le 05/10/2018 à 15:49, Camille Sauvage a écrit :

je sors d'une épique bataille pour permettre à nos usagers de téléverser des images via un formulaire Formidable.

Quand j'ai découvert que cvt-upload + Formidable = téléversement de fichiers dans un formulaire, je me suis jeté dessus car c'est un besoin discuté depuis longtemps.

Le hic, c'est que seul le téléversement de fichiers non graphiques fonctionnait chez moi. Les PDF, par exemple passaient parfaitement, alors que pour les GIF, JPEG et PNG, rien a faire, toujours les message

"Le fichier « XXXX » n’a pas pu être stocké correctement par le système. Contactez le webmestre."

En déroulant les appels des fonctions, j'ai vu qu'une fois la fonction _verifier() de cvt-upload passée, le fichier temporaire qui était créé entre le téléversement par PHP (dans le répertoire /tmp/) et celui dans le tmp/ du site (ou l'instance) SPIP avait disparu.

Donc quand Formidable essayait de recopier ce fichier à son emplacement de stockage définitif, le fichier manquait et générait cette erreur.

À force de chercher, je me suis rendu compte que le problème venait de l'invocation de la noisette :
cvt-upload/formulaires/inc-cvtupload-fichier.html
et plus précisément du filtre "_image_reduire_base64"

En effet, une fois que le filtre a fait sa conversion en base 64, le fichier original est supprimé car "Ceci permet que la vignette ne soit pas conservée dans local/ et donc évite que la vignette d'une image potentiellement confidentielle soit visible" (documentation de la fonction).

Sauf que là, ça ne fait pas notre affaire.

Du coup je propose ce petit patch en PJ. Si je suis le seul à avoir expérimenté ce problème et que certain.e.s parmi vous l'ont contourné depuis longtemps, je veux bien avoir l'explication de comment ça marchait avant pour vous.

Si vous voulez que je le commit, n'hésitez pas.

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

merci pour ton rapport de bugue. Le patch lui-même n'est à mon avis pas le bon, car il faut simplement s'assurer que l'original soit différent du fichier réduit au sein de la fonction base_64, quelque soit le type de fichier. Le problème peut arriver dès lors que la fonction de compression d'image n'est pas executé, pour une raison y ou y.

Maïeul
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

surtout il est important pour des raisons de confidentialités que la vignette généré dans local soit bien détruite...

je viens de faire un commit qui vérifie ce point. Bon par contre mes commits d'hier ont cassé la generation de vignette, mais on va voir comment résoudre cela.

6

Le 06/10/2018 à 09:59, Maïeul a écrit :

Le 06/10/2018 à 09:43, Maïeul a écrit :

Le 05/10/2018 à 15:49, Camille Sauvage a écrit :

je sors d'une épique bataille pour permettre à nos usagers de téléverser des images via un formulaire Formidable.

Quand j'ai découvert que cvt-upload + Formidable = téléversement de fichiers dans un formulaire, je me suis jeté dessus car c'est un besoin discuté depuis longtemps.

Le hic, c'est que seul le téléversement de fichiers non graphiques fonctionnait chez moi. Les PDF, par exemple passaient parfaitement, alors que pour les GIF, JPEG et PNG, rien a faire, toujours les message

"Le fichier « XXXX » n’a pas pu être stocké correctement par le système. Contactez le webmestre."

En déroulant les appels des fonctions, j'ai vu qu'une fois la fonction _verifier() de cvt-upload passée, le fichier temporaire qui était créé entre le téléversement par PHP (dans le répertoire /tmp/) et celui dans le tmp/ du site (ou l'instance) SPIP avait disparu.

Donc quand Formidable essayait de recopier ce fichier à son emplacement de stockage définitif, le fichier manquait et générait cette erreur.

À force de chercher, je me suis rendu compte que le problème venait de l'invocation de la noisette :
cvt-upload/formulaires/inc-cvtupload-fichier.html
et plus précisément du filtre "_image_reduire_base64"

En effet, une fois que le filtre a fait sa conversion en base 64, le fichier original est supprimé car "Ceci permet que la vignette ne soit pas conservée dans local/ et donc évite que la vignette d'une image potentiellement confidentielle soit visible" (documentation de la fonction).

Sauf que là, ça ne fait pas notre affaire.

Du coup je propose ce petit patch en PJ. Si je suis le seul à avoir expérimenté ce problème et que certain.e.s parmi vous l'ont contourné depuis longtemps, je veux bien avoir l'explication de comment ça marchait avant pour vous.

Si vous voulez que je le commit, n'hésitez pas.

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

merci pour ton rapport de bugue. Le patch lui-même n'est à mon avis pas le bon, car il faut simplement s'assurer que l'original soit différent du fichier réduit au sein de la fonction base_64, quelque soit le type de fichier. Le problème peut arriver dès lors que la fonction de compression d'image n'est pas executé, pour une raison y ou y.

Maïeul
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

surtout il est important pour des raisons de confidentialités que la vignette généré dans local soit bien détruite...

je viens de faire un commit qui vérifie ce point. Bon par contre mes commits d'hier ont cassé la generation de vignette, mais on va voir comment résoudre cela.
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

voilà, la toute dernière version de cvt-upload genere les vignettes mais n'efface pas les fichiers temporaires...

7

Le 05/10/2018 à 22:35, nicod_ a écrit :

Dans des saisies, ou dans formidable ?

Dans Formidable, avec un formulaire qui a un champ fichier de deux
fichiers .

Bizarrement ça ne fait pas le même comportement à chaque envoi. Et le
plus amusant c'est que moi, de mon ordi, en anonyme hein donc sans
rapport avec des autorisations, ça a marché à chaque fois à 100%. Mais
les proprios du site, ou Charles depuis son ordi, là ça merdait.

Et il y avait deux bugs :
- parfois le coup du fichier qui veut pas s'enregistrer, avec message
d'erreur et email qui part à un admin
- et le form qui ne se poste pas et qui met juste "Erreur" en haut et un
retour 401 je crois dans le Réseau du navigateur, et quand on reposte,
dans l'admin il y a un réponse avec tous les champs vides, et une
réponse avec les champs remplis…

--
RastaPopoulos

8

Le 06/10/2018 à 10:09, Maïeul a écrit :

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

voilà, la toute dernière version de cvt-upload genere les vignettes mais n'efface pas les fichiers temporaires...

https://zone.spip.net/trac/spip-zone/changeset/111886

Nope : link(), comme symlink() est souvent bloqué sur les hébergements (étant une faille potentielle de sécu).

Faut trouver une autre solution :slight_smile:

MM.

9

Le 06/10/2018 à 10:20, Matthieu Marcillaud a écrit :

Le 06/10/2018 à 10:09, Maïeul a écrit :

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

voilà, la toute dernière version de cvt-upload genere les vignettes mais n'efface pas les fichiers temporaires...

https://zone.spip.net/trac/spip-zone/changeset/111886

Nope : link(), comme symlink() est souvent bloqué sur les hébergements (étant une faille potentielle de sécu).

Faut trouver une autre solution :slight_smile:

MM.
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

arf! j'ai re reflechi. En fait la résolution de bug était pas la bonne. Il faut bien que dans tmp/cvt-upload on ait le fichier avec extension si on est au format d'image.
C'est juste que le bug qui faisait disparaire temporairement le fichier vide avait entrainer les différents bugs.

En tout cas maintenant tout devrait être bon au niveau generation vignette + formulaire upload html 5.

10

Le 06/10/2018 à 10:17, RastaPopoulos a écrit :

Le 05/10/2018 à 22:35, nicod_ a écrit :

Dans des saisies, ou dans formidable ?

Dans Formidable, avec un formulaire qui a un champ fichier de deux
fichiers .

Bizarrement ça ne fait pas le même comportement à chaque envoi. Et le
plus amusant c'est que moi, de mon ordi, en anonyme hein donc sans
rapport avec des autorisations, ça a marché à chaque fois à 100%. Mais
les proprios du site, ou Charles depuis son ordi, là ça merdait.

Et il y avait deux bugs :
- parfois le coup du fichier qui veut pas s'enregistrer, avec message
d'erreur et email qui part à un admin
- et le form qui ne se poste pas et qui met juste "Erreur" en haut et un
retour 401 je crois dans le Réseau du navigateur, et quand on reposte,
dans l'admin il y a un réponse avec tous les champs vides, et une
réponse avec les champs remplis…

pour le premier point, je pense que ce qui passait était le suivant:
- on demande de generer une vignette
- pour x raison, SPIP ne genere pas vraiment la vignette, et renvoi juste l'url du fichier
- du coup la fonction _imagereduire_base64 supprimait non pas la vignette mais le fichier dans le dossier tmp
- conséquent -> l'image n'était pas trouvé.

Ce bug est normalement résolu avec le commit 111885
Pour l'autre point, j'avoue ne pas savoir en l'absence de log...

11

Le 06/10/2018 à 12:58, Maïeul a écrit :

Pour l'autre point, j'avoue ne pas savoir en l'absence de log...

J'ai mis à jour cvt-upload, il y a toujours le 2ème problème.
Voilà les logs :

2018-10-06 11:54:57 151.127.7.63 (pid 9592) :Pub:info: include_spip formulaires/formidable/saisies.php non trouve
2018-10-06 11:54:57 151.127.7.63 (pid 9592) :Pub:info: calcul (78.998 ms) [plugins/svn/cvt-upload/formulaires/inc-cvtupload-fichier] tmp_name=/var/www/site/tmp/cvtup.., name=snowboard_03.jpg, extension=jpg, vignette=/var/www/site/tmp/cvtup.., mime=image/jpeg, taille=545465, form=formidable, infos_encodees=GuAg47AnsWatw5RwAc3lHby56cV.., crochets=[fichiers_1][0], champ=fichiers_1[0], lang=ww, date='2018-10-06 11:54:57', date_default=1, date_redac='2018-10-06 11:54:57', date_redac_default=1 (8212 octets)
2018-10-06 11:54:57 151.127.7.63 (pid 9592) :Pub:!INFO: {"post":{"var_ajax":"form","formulaire_action":"formidable","formulaire_action_args":"...","id_formulaire":1,"formidable_afficher_apres":"formulaire","bigup_retrouver_fichiers":"1","fichiers_1":{"1":""},"mechantrobot":""},"files":{"fichiers_1":{"name":["snowboard_03.jpg"],"type":["image\/jpeg"],"tmp_name":["\/var\/www\/nidecker\/tmp\/cvtupload\/formidable_MSXobf.jpg"],"error":[0],"size":[545465]}}}
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: Recuperer /config/fichiers/formidable/formulaire_1/test.txt sur tls://site.ltd:443 par
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:ERREUR: Erreur connexion 110 Connection timed out
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: ECHEC init_http https://site.ltd/config/fichiers/formidable/formulaire_1/test.txt
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: Création du dossier formulaire_1
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: creation config/fichiers/formidable/formulaire_1/reponse_22/
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: creation config/fichiers/formidable/formulaire_1/reponse_22/fichiers_1/
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: Enregistrement du fichier config/fichiers/formidable/formulaire_1/reponse_22/fichiers_1/snowboard_03.jpg
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: Recuperer /config/fichiers/formidable/formulaire_1/test.txt sur tls://site.ltd:443 par
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:ERREUR: Erreur connexion 110 Connection timed out
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: ECHEC init_http https://site.ltd/config/fichiers/formidable/formulaire_1/test.txt
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: Création du dossier formulaire_1
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: redirige formulaire ajax: /site/article/?id_formulaire=1&var_ajax=form&formulaire_action=formidable&formulaire_action_args=...&formidable_afficher_apres=formulaire&bigup_retrouver_fichiers=1&fichiers_1=

12

Le 06/10/2018 à 15:00, Charles Razack a écrit :

Le 06/10/2018 à 12:58, Maïeul a écrit :

Pour l'autre point, j'avoue ne pas savoir en l'absence de log...

J'ai mis à jour cvt-upload, il y a toujours le 2ème problème.
Voilà les logs :

2018-10-06 11:54:57 151.127.7.63 (pid 9592) :Pub:info: include_spip formulaires/formidable/saisies.php non trouve
2018-10-06 11:54:57 151.127.7.63 (pid 9592) :Pub:info: calcul (78.998 ms) [plugins/svn/cvt-upload/formulaires/inc-cvtupload-fichier] tmp_name=/var/www/site/tmp/cvtup.., name=snowboard_03.jpg, extension=jpg, vignette=/var/www/site/tmp/cvtup.., mime=image/jpeg, taille=545465, form=formidable, infos_encodees=GuAg47AnsWatw5RwAc3lHby56cV.., crochets=[fichiers_1][0], champ=fichiers_1[0], lang=ww, date='2018-10-06 11:54:57', date_default=1, date_redac='2018-10-06 11:54:57', date_redac_default=1 (8212 octets)
2018-10-06 11:54:57 151.127.7.63 (pid 9592) :Pub:!INFO: {"post":{"var_ajax":"form","formulaire_action":"formidable","formulaire_action_args":"...","id_formulaire":1,"formidable_afficher_apres":"formulaire","bigup_retrouver_fichiers":"1","fichiers_1":{"1":""},"mechantrobot":""},"files":{"fichiers_1":{"name":["snowboard_03.jpg"],"type":["image\/jpeg"],"tmp_name":["\/var\/www\/nidecker\/tmp\/cvtupload\/formidable_MSXobf.jpg"],"error":[0],"size":[545465]}}}

2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: Recuperer /config/fichiers/formidable/formulaire_1/test.txt sur tls://site.ltd:443 par
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:ERREUR: Erreur connexion 110 Connection timed out
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: ECHEC init_http https://site.ltd/config/fichiers/formidable/formulaire_1/test.txt
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: Création du dossier formulaire_1
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: creation config/fichiers/formidable/formulaire_1/reponse_22/
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: creation config/fichiers/formidable/formulaire_1/reponse_22/fichiers_1/
2018-10-06 11:55:07 151.127.7.63 (pid 9592) :Pub:info: Enregistrement du fichier config/fichiers/formidable/formulaire_1/reponse_22/fichiers_1/snowboard_03.jpg

2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: Recuperer /config/fichiers/formidable/formulaire_1/test.txt sur tls://site.ltd:443 par
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:ERREUR: Erreur connexion 110 Connection timed out
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: ECHEC init_http https://site.ltd/config/fichiers/formidable/formulaire_1/test.txt
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: Création du dossier formulaire_1
2018-10-06 11:55:17 151.127.7.63 (pid 9592) :Pub:info: redirige formulaire ajax: /site/article/?id_formulaire=1&var_ajax=form&formulaire_action=formidable&formulaire_action_args=...&formidable_afficher_apres=formulaire&bigup_retrouver_fichiers=1&fichiers_1=

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

c'est bien le bug 401?
ca m'a tout l'air d'etre un bug au moment où on vérifie automatiquement que l'accès en http au fichier dans config/fichiers n'est pas possible. J'imagine que le serveur n'autorise pas à récupérer en distant lui-meme (ca m'est deja arrivé).
Est-ce que tu peux faire un test en essayant de récupérer en document distant un document qui se situe deja sur le serveur?

Maïeuél.

13

Le 07/10/2018 à 19:54, Maïeul a écrit :

c'est bien le bug 401?
ca m'a tout l'air d'etre un bug au moment où on vérifie automatiquement que l'accès en http au fichier dans config/fichiers n'est pas possible. J'imagine que le serveur n'autorise pas à récupérer en distant lui-meme (ca m'est deja arrivé).
Est-ce que tu peux faire un test en essayant de récupérer en document distant un document qui se situe deja sur le serveur?

Maïeuél.

Ah oui bien vu, impossible de téléverser un document distant qui se trouve sur le serveur.
(Testé avec l'ajout de coument, onglet "depuis internet", et le document est bien accessible en http depuis un navigateur).

14

Le dimanche 07 octobre 2018 à 20:11 +0200, Charles Razack a écrit :

Le 07/10/2018 à 19:54, Maïeul a écrit :
> c'est bien le bug 401?
> ca m'a tout l'air d'etre un bug au moment où on vérifie
> automatiquement que l'accès en http au fichier dans config/fichiers
> n'est pas possible. J'imagine que le serveur n'autorise pas à
> récupérer en distant lui-meme (ca m'est deja arrivé).
> Est-ce que tu peux faire un test en essayant de récupérer en
> document
> distant un document qui se situe deja sur le serveur?
>
> Maïeuél.
>

Ah oui bien vu, impossible de téléverser un document distant qui se
trouve sur le serveur.
(Testé avec l'ajout de coument, onglet "depuis internet", et le
document
est bien accessible en http depuis un navigateur).

du coup, je sais pas trop comment résoudre ce problème. C'est un
problème de config serveur, mais il faudrait pouvoir en tenir compte,
sans casser la présence d'un test de sécurité.

J'ai pas vraiment de bonne solution.

15

Au moins on a mis le doigt sur le problème de config du serveur, merci.
Effectivement même un simple wget ne fonctionne pas, il faut qu’on règle ça avec notre hébergeur.

Il y a quand même 2 choses que je ne m’explique pas :

  • D’une part sur le serveur, l’erreur n’est pas systématique (RastaPopoulos n’arrive pas à reproduire, moi c’est quasiment tout le temps)
  • Et quand ça se produit, en revalidant le formulaire là ça passe.

J’ai aussi rencontré le problème épisodiquement en local, mais là pas de problème de config ou autre, aucun souci pour récupérer des documents locaux.

On essaiera d’investiguer un peu plus, là on a pas trop eu le temps de regarder en détail.

16

il y a peut être autre chose alors. Mais quand même ca m'a l'air bien
lié...

Le dimanche 07 octobre 2018 à 20:38 +0200, Charles Razack a écrit :

Au moins on a mis le doigt sur le problème de config du serveur,
merci.
Effectivement même un simple wget ne fonctionne pas, il faut qu'on
règle ça avec notre hébergeur.
Il y a quand même 2 choses que je ne m'explique pas :
- D'une part sur le serveur, l'erreur n'est pas systématique
(RastaPopoulos n'arrive pas à reproduire, moi c'est quasiment tout le
temps)
- Et quand ça se produit, en revalidant le formulaire là ça passe.
J'ai aussi rencontré le problème épisodiquement en local, mais là pas
de problème de config ou autre, aucun souci pour récupérer des
documents locaux.
On essaiera d'investiguer un peu plus, là on a pas trop eu le temps de
regarder en détail.
Le 07/10/2018 à 20:13, Maïeul Rouquette a écrit :
> du coup, je sais pas trop comment résoudre ce problème. C'est un
> problème de config serveur, mais il faudrait pouvoir en tenir
> compte,
> sans casser la présence d'un test de sécurité.
>
> J'ai pas vraiment de bonne solution.

17

Salut Maïeul,

C'est juste que le bug qui faisait disparaire temporairement le fichier vide avait entrainer les différents bugs.

En tout cas maintenant tout devrait être bon au niveau generation vignette + formulaire upload html 5.

je viens d'installer la version issue de ton dernier commit ! Top, mes vignettes sont générées, le téléversement accepté et bien rangé.

Bref ça ronronne :slight_smile:

Merci
--
Camille

18

Le 08/10/2018 à 09:52, Camille Sauvage a écrit :

Salut Maïeul,

C'est juste que le bug qui faisait disparaire temporairement le fichier vide avait entrainer les différents bugs.

En tout cas maintenant tout devrait être bon au niveau generation vignette + formulaire upload html 5.

je viens d'installer la version issue de ton dernier commit ! Top, mes vignettes sont générées, le téléversement accepté et bien rangé.

Bref ça ronronne :slight_smile:

Merci
--
Camille
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

super, merci pour le retour