[SPIP Zone] Upload avec formidable, point d'étape

Archives Zone
1

Salut à tou·te·s,

Comme vous avez pu le constater, j'ai pas mal avancé ce week-end dans ces histoires de saisies pour upload, dans l'espoir de pouvoir à terme envoyer des upload dans formidables.

Par rapport à la liste fixée lundi, j'ai fait toutes les étapes 1 à 5, il ne reste donc que l'étape 6, c'est à dire l'envoi dans formidable.

Pour le moment il est donc possible:
- d'avoir une saisie 'fichiers' permettant, en HTML 4, d'envoyer un à N fichiers
- de vérifier cette saisie selon plusieurs critères comme le mime type, le poids, la taille
- le cas échéant, effacer de $_FILES les fichiers qui ne répondent pas à ces critères
- d'avoir un formulaire constructeur d'une liste de saisie (type formidable) qui propose pour la saisie fichier les options de vérification possible
- d'utiliser saisies_verifier() sur une liste de saisie comprenant des saisies de type fichiers
- d'obtenir, in fine, un $_FILES transparent, à la seule différent que $_FILES[champ]['tmp_name'][x] renvoie à un fichier situé dans tmp/cvtupload et non pas à l'endroit où APACHE le place par défaut

Voir des copies d'écran :
https://framapic.org/HvoVhaVKspNP/PzifNMUeUDaY.png
https://framapic.org/oOI8JQxWJRyO/WHr1yrS4Qjn4.png
https://framapic.org/y9SKUFt0MdLW/iNAufkeKdRBC.png

Ce qui serait chouette d'améliorer, mais pas urge:
- avoir une variante de la saisie qui fonctionne en js/html5 pour faire du drag&drog et avoir des belles choses
- avoir des messages d'erreurs si les fichiers sont mal uploadés (voir http://ch1.php.net/manual/fr/features.file-upload.errors.php)
- trouver comment faire pour que la liste des types mime dans le formulaire de construction d'une saisie fichiers ne s'affiche que lorsqu'on a coché la case 'Un type Mime précisé ci-dessous"

La semaine prochaine (samedi/dimanche), je m'attaquerai à l'intégration plénière dans formidable.

Voici mes propositions pour le traitement:
- si les réponses sont enregistrées:
  - on stocke dans config/fichiers_formidable/formulaire_XX/reponse_XX
  - dans la présentation des réponses, on propose une action, qui permet, si jamais on a le droit de voir les réponses, de télécharger le fichier
  - également une action qui permet de le mettre dans la médiathèque, mais dans ce cas on fait une copie: la version dans config/fichiers_formidable/formulaire_XX/reponse_XX ne bouge jamais
- si les réponses sont envoyées par mail:
  - si réponses enregistrées -> un lien vers l'action, avec une sécurité (comme dans les notifications de forum, le lien qui permet de télécharger les fichiers)
  - si les réponses ne sont pas enregistrées:
    - on stocke dans config/fichiers_formidable_courriel/reponse_timestamp_hash_des_reponses
    - on envoie un lien d'action pour télécharger cela
    - on efface régulièrement les fichiers anciens(selon une constante à nommer et à fixer à 48 heure?), pour que cela ne traine pas trop longtemps

J'attends vos réactions sur ces points

Bises

Maïeul

2

Maïeul a écrit le 11/12/2016 à 22:34 :
Salut !

config/fichiers_formidable/formulaire_XX/reponse_XX ne bouge jamais

c'est pas IMG/ au lieu de config/ ?
Et par prudence, avec un nom de fichier qui dépend de l'alea du site pour ne pas pouvoir être deviné par un hackeur ?

J'attends vos réactions sur ces points

Merci !

--
RealET

3

Le 11.12.16 à 22:40, RealET a écrit :

Maïeul a écrit le 11/12/2016 à 22:34 :
Salut !

config/fichiers_formidable/formulaire_XX/reponse_XX ne bouge jamais

c'est pas IMG/ au lieu de config/ ?
Et par prudence, avec un nom de fichier qui dépend de l'alea du site
pour ne pas pouvoir être deviné par un hackeur ?

Non, l'idée est de mettre dans une répertoire inaccessible depuis l'extérieur. Seule une action (avec authentifcation donc) permettra de récupérer ces fichiers, et éventuellement de les diffuser sur un lieu public.

J'attends vos réactions sur ces points

Merci !

--
Maïeul

4

Maïeul a écrit le 11/12/2016 à 23:23 :

Le 11.12.16 à 22:40, RealET a écrit :

Maïeul a écrit le 11/12/2016 à 22:34 :
Salut !

config/fichiers_formidable/formulaire_XX/reponse_XX ne bouge jamais

c'est pas IMG/ au lieu de config/ ?
Et par prudence, avec un nom de fichier qui dépend de l'alea du site
pour ne pas pouvoir être deviné par un hackeur ?

Non, l'idée est de mettre dans une répertoire inaccessible depuis
l'extérieur. Seule une action (avec authentifcation donc) permettra de
récupérer ces fichiers, et éventuellement de les diffuser sur un lieu
public.

Ce qui peut rendre un dossier inaccessible depuis l'extérieur, c'est un .htaccess
Rien n'interdit que le plugin crée le .htaccess dans un sous-dossier de IMG/
Et IMG/ c'est LE dossier que l'on sauvegarde pour transférer un site d'un hébergeur à un autre.

--
RealET

5

Le 11.12.16 à 23:33, RealET a écrit :

Maïeul a écrit le 11/12/2016 à 23:23 :

Le 11.12.16 à 22:40, RealET a écrit :

Maïeul a écrit le 11/12/2016 à 22:34 :
Salut !

config/fichiers_formidable/formulaire_XX/reponse_XX ne bouge jamais

c'est pas IMG/ au lieu de config/ ?
Et par prudence, avec un nom de fichier qui dépend de l'alea du site
pour ne pas pouvoir être deviné par un hackeur ?

Non, l'idée est de mettre dans une répertoire inaccessible depuis
l'extérieur. Seule une action (avec authentifcation donc) permettra de
récupérer ces fichiers, et éventuellement de les diffuser sur un lieu
public.

Ce qui peut rendre un dossier inaccessible depuis l'extérieur, c'est un
.htaccess
Rien n'interdit que le plugin crée le .htaccess dans un sous-dossier de
IMG/
Et IMG/ c'est LE dossier que l'on sauvegarde pour transférer un site
d'un hébergeur à un autre.

effectivement, mais il y aussi une logique SPIP, qui dit que config -> permanent inaccessible
cela étant ton argument du transfert est pas idiot.

Attendons les avis des autres, notamment de Rastapopoulos et Cédric
qui avaient eu en premier cette idée de config/.

Peut-être qu'ils avaient un argument qui nous échappe encore.
--
Maïeul

6

Le 11/12/2016 à 23:39, Maïeul a écrit :

Peut-être qu'ils avaient un argument qui nous échappe encore.

IMG n'est pas fait pour être inaccessible, c'est une modif du fonctionnement prévu de ce dossier sinon. Les noms de dossiers sont gardés pour compatibilités etc, mais en vrai, dans le code interne de SPIP :
- IMG se nomme "permanent accessible"
- config se nomme "permanent inaccessible"

C'est donc logiquement "config" qui est censé stocker les infos non-temporaires, qui ont vocation à être toujours là, MAIS inaccessibles au public quand on y va par l'URL dans le navigateur.

"config" contient aussi par exemple la base SQLite quand on installe avec ce mode, et donc ce dossier *aussi* peut contenir des choses qu'on doit absolument migrer quand on bouge le site, ce n'est pas juste le connect.php.

--
RastaPopoulos

7

Le 12.12.16 à 01:42, RastaPopoulos a écrit :

Le 11/12/2016 à 23:39, Maïeul a écrit :

Peut-être qu'ils avaient un argument qui nous échappe encore.

IMG n'est pas fait pour être inaccessible, c'est une modif du
fonctionnement prévu de ce dossier sinon. Les noms de dossiers sont
gardés pour compatibilités etc, mais en vrai, dans le code interne de
SPIP :
- IMG se nomme "permanent accessible"
- config se nomme "permanent inaccessible"

C'est donc logiquement "config" qui est censé stocker les infos
non-temporaires, qui ont vocation à être toujours là, MAIS inaccessibles
au public quand on y va par l'URL dans le navigateur.

"config" contient aussi par exemple la base SQLite quand on installe
avec ce mode, et donc ce dossier *aussi* peut contenir des choses qu'on
doit absolument migrer quand on bouge le site, ce n'est pas juste le
connect.php.

oui, effectivement. Et il serait bon de ne pas introduire d'exception à la règle. Donc config.

--
Maïeul

8

Je propose un dossier config/fichiers/
avec un sous repertoire formidable/ dans lequel il fait ce qu'il veut

Ainsi on aura un config/fichiers/ symétrique de config/bases/, l'un et l'autre étant à migrer en cas de présence

L'autre intérêt d'utiliser ce dossier d'un point de vue sécurité est qu'il a *normalement* été protégé à l'installation, par construction.

Le .htaccess n'est pas suffisant pour protéger un sous-dossier de IMG car on ne peut pas garantir qu'il soit pris en compte (configuration apache ou autre serveur type nginx), ce qui serait donc une faille de sécurité grave.

Néanmoins, il serait préférable que dans formidable, quand on configurera la sauvegarde d'un champ fichier, il y ait
1/ une vérification que le dossier config/fichiers/formidable est bien accessible en écriture (en créant le dossier au passage)
2/ d'y déposer un fichier test en demandant à l'utilisateur de vérifier qu'il ne peut effectivement pas accéder au fichier concerné

(l'astuce peut être de mettre un message d'alerte 'ERREUR configuration non sécurisée' dans le fichier html test et de l'afficher via une iframe dans le navigateur, qui ne s'affichera donc qu'en cas de configuration non sécurisée)

--
Cédric

RastaPopoulos a écrit :

Le 11/12/2016 à 23:39, Maïeul a écrit :

Peut-être qu'ils avaient un argument qui nous échappe encore.

IMG n'est pas fait pour être inaccessible, c'est une modif du
fonctionnement prévu de ce dossier sinon. Les noms de dossiers sont
gardés pour compatibilités etc, mais en vrai, dans le code interne de
SPIP :
- IMG se nomme "permanent accessible"
- config se nomme "permanent inaccessible"

C'est donc logiquement "config" qui est censé stocker les infos
non-temporaires, qui ont vocation à être toujours là, MAIS inaccessibles
au public quand on y va par l'URL dans le navigateur.

"config" contient aussi par exemple la base SQLite quand on installe
avec ce mode, et donc ce dossier *aussi* peut contenir des choses qu'on
doit absolument migrer quand on bouge le site, ce n'est pas juste le
connect.php.

9

Oui,

cela m'a l'air bien.

Reste à voir en pratique comment on fonctionne. Dans ma tête, il n'y avait pas de configuration spécifique lors de l'ajout d'un champ fichiers, mais des actions implicites.

Mais effectivement, les vérifications de sécurités doivent se faire au moment de la sauvegarde du traitement, si on détecte l'existence d'un ou plusieurs champs fichiers.

Le 12 déc. 2016 à 11:53, Cédric Morin <cedric@yterium.com> a écrit :

Je propose un dossier config/fichiers/
avec un sous repertoire formidable/ dans lequel il fait ce qu'il veut

Ainsi on aura un config/fichiers/ symétrique de config/bases/, l'un et l'autre étant à migrer en cas de présence

L'autre intérêt d'utiliser ce dossier d'un point de vue sécurité est qu'il a *normalement* été protégé à l'installation, par construction.

Le .htaccess n'est pas suffisant pour protéger un sous-dossier de IMG car on ne peut pas garantir qu'il soit pris en compte (configuration apache ou autre serveur type nginx), ce qui serait donc une faille de sécurité grave.

Néanmoins, il serait préférable que dans formidable, quand on configurera la sauvegarde d'un champ fichier, il y ait
1/ une vérification que le dossier config/fichiers/formidable est bien accessible en écriture (en créant le dossier au passage)
2/ d'y déposer un fichier test en demandant à l'utilisateur de vérifier qu'il ne peut effectivement pas accéder au fichier concerné

(l'astuce peut être de mettre un message d'alerte 'ERREUR configuration non sécurisée' dans le fichier html test et de l'afficher via une iframe dans le navigateur, qui ne s'affichera donc qu'en cas de configuration non sécurisée)

--
Cédric

RastaPopoulos a écrit :

Le 11/12/2016 à 23:39, Maïeul a écrit :

Peut-être qu'ils avaient un argument qui nous échappe encore.

IMG n'est pas fait pour être inaccessible, c'est une modif du
fonctionnement prévu de ce dossier sinon. Les noms de dossiers sont
gardés pour compatibilités etc, mais en vrai, dans le code interne de
SPIP :
- IMG se nomme "permanent accessible"
- config se nomme "permanent inaccessible"

C'est donc logiquement "config" qui est censé stocker les infos
non-temporaires, qui ont vocation à être toujours là, MAIS inaccessibles
au public quand on y va par l'URL dans le navigateur.

"config" contient aussi par exemple la base SQLite quand on installe
avec ce mode, et donc ce dossier *aussi* peut contenir des choses qu'on
doit absolument migrer quand on bouge le site, ce n'est pas juste le
connect.php.

10

Bonjour,

Grand merci pour vous être attaqué à ce problème !

Même si je ne me sens pas forcément pour aider directement dans le code sur ce sujet et si j'imagine que vous avez mis en place les ressources nécessaires à cet effort (qu'elles soient techniques ou autres), sachez que nous sommes prêts à contribuer si besoin (je ne sais pas, hébergement, tests, ....), n'hésitez pas à nous demander (liste ou privé).

Je ne sais pas si vous avez déjà choisi un système d'upload mais pour un projet interne j'en ai essayé pas mal et celui qui a le mieux marché pour moi était:

Encore merci, on suit vos progrès avec attention.

Le 12/12/2016 à 12:05, Maïeul Rouquette a écrit :

Oui,

cela m'a l'air bien.

Reste à voir en pratique comment on fonctionne. Dans ma tête, il n'y avait pas de configuration spécifique lors de l'ajout d'un champ fichiers, mais des actions implicites.

Mais effectivement, les vérifications de sécurités doivent se faire au moment de la sauvegarde du traitement, si on détecte l'existence d'un ou plusieurs champs fichiers.

Le 12 déc. 2016 à 11:53, Cédric Morin <cedric@yterium.com> a écrit :

Je propose un dossier config/fichiers/
avec un sous repertoire formidable/ dans lequel il fait ce qu'il veut

Ainsi on aura un config/fichiers/ symétrique de config/bases/, l'un et l'autre étant à migrer en cas de présence

L'autre intérêt d'utiliser ce dossier d'un point de vue sécurité est qu'il a *normalement* été protégé à l'installation, par construction.

Le .htaccess n'est pas suffisant pour protéger un sous-dossier de IMG car on ne peut pas garantir qu'il soit pris en compte (configuration apache ou autre serveur type nginx), ce qui serait donc une faille de sécurité grave.

Néanmoins, il serait préférable que dans formidable, quand on configurera la sauvegarde d'un champ fichier, il y ait
1/ une vérification que le dossier config/fichiers/formidable est bien accessible en écriture (en créant le dossier au passage)
2/ d'y déposer un fichier test en demandant à l'utilisateur de vérifier qu'il ne peut effectivement pas accéder au fichier concerné

(l'astuce peut être de mettre un message d'alerte 'ERREUR configuration non sécurisée' dans le fichier html test et de l'afficher via une iframe dans le navigateur, qui ne s'affichera donc qu'en cas de configuration non sécurisée)

--
Cédric

RastaPopoulos a écrit :

Le 11/12/2016 à 23:39, Maïeul a écrit :

Peut-être qu'ils avaient un argument qui nous échappe encore.

IMG n'est pas fait pour être inaccessible, c'est une modif du
fonctionnement prévu de ce dossier sinon. Les noms de dossiers sont
gardés pour compatibilités etc, mais en vrai, dans le code interne de
SPIP :
- IMG se nomme "permanent accessible"
- config se nomme "permanent inaccessible"

C'est donc logiquement "config" qui est censé stocker les infos
non-temporaires, qui ont vocation à être toujours là, MAIS inaccessibles
au public quand on y va par l'URL dans le navigateur.

"config" contient aussi par exemple la base SQLite quand on installe
avec ce mode, et donc ce dossier *aussi* peut contenir des choses qu'on
doit absolument migrer quand on bouge le site, ce n'est pas juste le
connect.php.

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

--
Pierre

11

Le 13.12.16 à 10:40, Zedd a écrit :

Bonjour,

Je ne sais pas si vous avez déjà choisi un système d'upload mais pour un
projet interne j'en ai essayé pas mal et celui qui a le mieux marché
pour moi était:
jQuery Upload File Plugin Demo

Encore merci, on suit vos progrès avec attention.

comme j'explique en début de message, le but est pour le moment d'avoir un système qui marche indépendamment de javascript et de HTML5. Ce problème là viendra en tout dernier, c'est juste un souci d'interface (et pour le coup je suis très peu compétent en ce domaine)
--
Maïeul