Bonjour tout le monde !
Alors je vais commencer par ceci:
En ce moment, je travail sur un autre aspect du plugin, a savoir son intégration en tant que saisie. Je ne suis pas encore certain que cela va aboutir, il y a encore pas mal de problèmes à résoudre.
Je vois que tu as fusionné les 2 formulaires d'upload de logo et de documents dans un seul formulaires/uploadhtml5
En regardant le code php Connexion · GitLab , il me semble que ce serait mieux s'ils étaient séparés (il n'y a que des if/else).
Quand au html, il est pour l'instant court et pourrait être dupliqué, ou sinon, formulaires/uploadhtml5_logo pourrait simplement contenir un #INCLURE du premier.
Qu'en penses-tu ? je peux m'en occuper si tu es d'acco
En effet, je préfère avoir 2 if/else plutôt que 2 fichiers, cela me parait plus simple à maintenir. Le même formulaire pour géré tout les aspects "upload". D'autant que si je ne m'abuse, le futur des logos est assez incertain. Une fusion avec le système de document serait dans les cartons.
Après, ce n'est vraiment qu'une préférence. Je préfère ne pas avoir à reporter des modifications dans plusieurs fichiers, donc j'ai tendance à centraliser le code.
Pour certains sites qui sont limités taille d'upload, on a besoin de pouvoir envoyer de plus gros fichiers. Exemple, des PDF de 5Mo alors que l'upload PHP n'autorise que 2Mo… Une solution utilisée est de tenter d'envoyer le fichier par morceaux (chunk) si c'est possible .
J'ai déjà eu cette demande dans les commentaires de contrib (cf: Formulaire d'upload en html5 - SPIP-Contrib).
Dropzone, dans son état actuel à l'avantage de ce brancher directement sur les fonctions du core de SPIP.
En passant par un "Chunk" il faudrait implémenter sa propre fonction de chargement de fichier.
Je pars du principe que le Core de SPIP est stable et que donc je dois attendre qu'il supporte les chunk avant de le proposer dans DropZone. Si DropZone l'ajoute un jour.
Il y a d'autres questions que soulève cette technique:
Est-ce que ce n'est pas une mauvaise idée: dans la mesure ou l'hébergeur impose une limite, est-ce que ce n'est pas avec lui qu'il faut régler ce genre de problème ?
Est-ce qu'il ne va pas râler si je (et tout le monde) contourne une limite qu'il m'impose ?
Sur le plan de la sécurité est-ce que cela ne change pas ?
La seule protection contre l'upload massif serait un protection javascript, php ne connaissant pas la taille total du fichier uploader en Chunk. Si un attaquant contourne javascript et upload des fichiers de plusieurs Go à la chaine ?
Dans la mesure ou l'on pourrait utiliser cela sur l'espace publique (qui sait avec la saisie upload ?), cela me parait être un risque réel.
Est-ce vraiment fiable comme technique ? Les fichiers ne sont jamais altéré ?
Bref, cette idée ne m'enchante pas, car je trouve que contourner des limites imposée par les hébergeurs c'est assez moyen et devrait ce régler avec eux. Ou changer d'hébergement.
Est-ce que je pourrais tenter d'intégrer cette solution à ce plugin ? Par défaut ? en option ? ou préfères tu que ce plugin ne s'occupe pas de cela et que ce soit fait dans un autre plugin si ça doit être fait ?
Dans la mesure ou DropZone ne propose pas cette option, je pense que ce serai plus sage d'avoir un autre plugin basé, peut être, sur une autre librairie.
Cela permettrai aussi de gérer autrement les problèmes de sécurités. Par exemple, en interdisant son utilisation dans l'espace publique.
Pour ma part, je me dis que pour un utilisateur qui installe le plugin, seule la configuration du plugin qui dit pas plus de 5Mo devrait entrer en jeu ; peut importe si PHP est limité à 2Mo et la manière derrière d'y arriver (et donc mettre ce fonctionnement par défaut, et non désactivable).
Comme dit plus haut, je pense justement que contourner une limitation imposée présente des risques. S'il n'y avait pas de problème, il n'y aurai pas de limite.
Après, je me trompe peut être.
--
Didier
Le 29/10/15 19:24, Matthieu Marcillaud a écrit :
Bonjour Didier, et la liste,
2 points à discuter :
1) Séparer les formulaires logo / documents ?
Je vois que tu as fusionné les 2 formulaires d'upload de logo et de documents dans un seul formulaires/uploadhtml5
En regardant le code php Connexion · GitLab , il me semble que ce serait mieux s'ils étaient séparés (il n'y a que des if/else).
Quand au html, il est pour l'instant court et pourrait être dupliqué, ou sinon, formulaires/uploadhtml5_logo pourrait simplement contenir un #INCLURE du premier.
Qu'en penses-tu ? je peux m'en occuper si tu es d'accord.
2) Envoi de gros fichiers (chunk)
Pour certains sites qui sont limités taille d'upload, on a besoin de pouvoir envoyer de plus gros fichiers. Exemple, des PDF de 5Mo alors que l'upload PHP n'autorise que 2Mo… Une solution utilisée est de tenter d'envoyer le fichier par morceaux (chunk) si c'est possible .
Certaines librairies d'upload le proposent directement, mais pas dropzone.js. Par contre un ticket Chunks? · Issue #339 · dropzone/dropzone · GitHub signale une solution (Issues · dropzone/dropzone · GitHub) qui pourrait peut être fonctionner, à l'aide d'une seconde librairie, resumable.js (http://www.resumablejs.com/).
Est-ce que je pourrais tenter d'intégrer cette solution à ce plugin ? Par défaut ? en option ? ou préfères tu que ce plugin ne s'occupe pas de cela et que ce soit fait dans un autre plugin si ça doit être fait ?
Pour ma part, je me dis que pour un utilisateur qui installe le plugin, seule la configuration du plugin qui dit pas plus de 5Mo devrait entrer en jeu ; peut importe si PHP est limité à 2Mo et la manière derrière d'y arriver (et donc mettre ce fonctionnement par défaut, et non désactivable).
Il faudra aussi un cron pour nettoyer les morceaux de fichiers uploadés dont l'upload n'a jamais été terminé. Peut être tous les morceaux plus vieux qu'une ou deux heures par exemple.
--
MM.
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone