Bonjour à tous,
Je m'occupe ces temps ci d'une application php qui nécessitera entre autre, le téléchargement de nombreux fichiers (centaines de milliers) en provenance de nombreux utilisateurs différents (quelques centaines). Je me demande qu'elle devrait être la politique de gestion des téléchargement de fichier d'une telle application. Quelles sont les bonnes pratiques en matière de gestion de téléchargement de fichiers utilisateurs sur un serveur http/php en générale? Tant du point de vu de la sécurité que de l'ergonomie (maintenance administrative, accès aux données pour le reporting, etc...).
Une autre question : Existe-t-il une "mailling list" de php France ?
Si quelques gourous de l'exploitation, spécialistes des contextes de production distribuées pouvait m'apporter leurs lumières...
Mais tous les avis sont les bienvenues.
Fred.
la communauté d'entraide francophone dédiée au PHP
Quelles sont les bonnes pratiques en matière "d'upload"?
Bonjour,
Sans être une gourou, pour le stockage il y a 2 écoles, le stockage en base de données et de stockage dans le système de fichier. Je ne suis pas partisan du stockage en base de données qui fournit souvent des performances avec mauvaise à mon gout.
Je penche plutôt pour un stockage dans le système de fichier avec une référence dans une base de donnée. En ayant un index auto-incrément, celui-ci peut être utilisé pour organiser le stockage en répertoire par découpage de l'identifiant. Pour un document "000012345678" il est possible de lui attribuer le répertoire de stockage 00/00/12/34/56/78 et de garder le nom choisi par l'utilisateur. De cette manière tu es sur d'avoir 100 sous-répertoires au maximum et de ne pas avoir de soucis pour les doublons de nom de fichier. Le nombre de fichier et de répertoire dans un répertoire influe sur les temps d'accès et il y a des limites max.
Il ne faut pas stocker les fichiers dans un répertoire accessible via le navigateur mais accessible à PHP. Imagines si quelqu'un upload un fichier toto.php et l'appelle depuis son navigateur. L'accès au document se fait par un script avec les fonctions header() pour le type mime et readfile() pour le contenu.
A propos du type mime, celui-ci est renvoyer dans la variable $_FILE. Il faut filtrer les type mime acceptable/acceptés. De manière général, il faut utiliser les posts du tableau $_FILE pour contrôle les upload.
Avec une utilisation du rewrite d'apache, il doit être possible d'appeler //www.toto.com/document/mondoc.doc et traiter la requete avec le script document.php?fichier=mondoc.doc
Autrement, tu peux regarder du coté de zope (plone ou CPS) qui doivent proposer des trucs sympa pour la gestion de documents avec des circuits de validations pour la publication et des possibilités d'édition en ligne via word ou autre et aussi de visualisation HTML. Mais ce n'est pas du PHP.
Sans être une gourou, pour le stockage il y a 2 écoles, le stockage en base de données et de stockage dans le système de fichier. Je ne suis pas partisan du stockage en base de données qui fournit souvent des performances avec mauvaise à mon gout.
Je penche plutôt pour un stockage dans le système de fichier avec une référence dans une base de donnée. En ayant un index auto-incrément, celui-ci peut être utilisé pour organiser le stockage en répertoire par découpage de l'identifiant. Pour un document "000012345678" il est possible de lui attribuer le répertoire de stockage 00/00/12/34/56/78 et de garder le nom choisi par l'utilisateur. De cette manière tu es sur d'avoir 100 sous-répertoires au maximum et de ne pas avoir de soucis pour les doublons de nom de fichier. Le nombre de fichier et de répertoire dans un répertoire influe sur les temps d'accès et il y a des limites max.
Il ne faut pas stocker les fichiers dans un répertoire accessible via le navigateur mais accessible à PHP. Imagines si quelqu'un upload un fichier toto.php et l'appelle depuis son navigateur. L'accès au document se fait par un script avec les fonctions header() pour le type mime et readfile() pour le contenu.
A propos du type mime, celui-ci est renvoyer dans la variable $_FILE. Il faut filtrer les type mime acceptable/acceptés. De manière général, il faut utiliser les posts du tableau $_FILE pour contrôle les upload.
Avec une utilisation du rewrite d'apache, il doit être possible d'appeler //www.toto.com/document/mondoc.doc et traiter la requete avec le script document.php?fichier=mondoc.doc
Autrement, tu peux regarder du coté de zope (plone ou CPS) qui doivent proposer des trucs sympa pour la gestion de documents avec des circuits de validations pour la publication et des possibilités d'édition en ligne via word ou autre et aussi de visualisation HTML. Mais ce n'est pas du PHP.
Salut Fredmj,
J'ai aussi une application ou l'utilisateur charge des fichiers, avec conversion automatique vers pdf, vérification antivirus et tout le reste. Pas des centaines de milliers, mais un joli tas quand même.
J'ai pas bien lu quel aspect de posait problème, alors je vais être large:
- le téléchargement lui-même: c'est le plus embêtant, en attendant Html5, le visiteur (dans le cas d'un fichier volumineux) est obligé d'attendre que le fichier se charge, sans barre de progression ni rien d'autre. Bien sur, il existe des alternatives: des applis flash qui s'intègrent dans la page, des applis Java (comme facebook un temps) ou quelque chose d'asynchrone avec ajax et une page php en iframe. Perso, de ce côté la, j'utilise le long-polling et un iframe, de cette façon, j'ai la barre de progression et l'avancée du traitement du fichier (vérification, antivirus, copie, ...). Dans une prochaine évolution, je pense m'orienter vers une solution semblable à ce que propose google docs, qui est pas mal foutue. Et vu le soin qu'ils accordent à leurs interfaces, ce n'est pas une mauvaise inspiration
- le stockage: le fichier lui-même est enregistré sous un nom généré (type uniqid() ) dans un répertoire temporaire, le temps de procéder aux diverses vérifications et conversions. Tout ce qui à attrait au fichier (son nom originel, son extension, sa taille, son expéditeur, etc...) est enregistré en DB.
Après traitement, il est enregistré sous un nom qui rassemble son identifiant interne au programme et une version "normalisée" (seulement lettres minuscules, de longueur définie) de son nom originel, sous sa nouvelle extension (pdf), tandis que la version originelle est enregistrée dans un répertoire "d'archive". Il faut se dire que le fichier ne contient que les donneés "brutes", les données utiles (meta-données) résidant dans la DB.
- l'accès: l'accès au fichier se passe bien sur par un script, qui vérifie les droits d'accès, récupère les données brutes dans l'arborescence et les exporte avec tous les headers utiles et particuliers (ce qui permet par-exemple le sur-lignage d'une requete de recherche dans le cas d'un pdf).
Du côté hardware, je n'ai encore rien de particulier, mais il s'agira probablement d'un volume LVM, permettant de faire des snapshots (utile pour les sauvegardes stables, sans demander d'interruptions) , et de l'agrandir à la volée en cas de besoin.
J'ai aussi une application ou l'utilisateur charge des fichiers, avec conversion automatique vers pdf, vérification antivirus et tout le reste. Pas des centaines de milliers, mais un joli tas quand même.
J'ai pas bien lu quel aspect de posait problème, alors je vais être large:
- le téléchargement lui-même: c'est le plus embêtant, en attendant Html5, le visiteur (dans le cas d'un fichier volumineux) est obligé d'attendre que le fichier se charge, sans barre de progression ni rien d'autre. Bien sur, il existe des alternatives: des applis flash qui s'intègrent dans la page, des applis Java (comme facebook un temps) ou quelque chose d'asynchrone avec ajax et une page php en iframe. Perso, de ce côté la, j'utilise le long-polling et un iframe, de cette façon, j'ai la barre de progression et l'avancée du traitement du fichier (vérification, antivirus, copie, ...). Dans une prochaine évolution, je pense m'orienter vers une solution semblable à ce que propose google docs, qui est pas mal foutue. Et vu le soin qu'ils accordent à leurs interfaces, ce n'est pas une mauvaise inspiration
- le stockage: le fichier lui-même est enregistré sous un nom généré (type uniqid() ) dans un répertoire temporaire, le temps de procéder aux diverses vérifications et conversions. Tout ce qui à attrait au fichier (son nom originel, son extension, sa taille, son expéditeur, etc...) est enregistré en DB.
Après traitement, il est enregistré sous un nom qui rassemble son identifiant interne au programme et une version "normalisée" (seulement lettres minuscules, de longueur définie) de son nom originel, sous sa nouvelle extension (pdf), tandis que la version originelle est enregistrée dans un répertoire "d'archive". Il faut se dire que le fichier ne contient que les donneés "brutes", les données utiles (meta-données) résidant dans la DB.
- l'accès: l'accès au fichier se passe bien sur par un script, qui vérifie les droits d'accès, récupère les données brutes dans l'arborescence et les exporte avec tous les headers utiles et particuliers (ce qui permet par-exemple le sur-lignage d'une requete de recherche dans le cas d'un pdf).
Du côté hardware, je n'ai encore rien de particulier, mais il s'agira probablement d'un volume LVM, permettant de faire des snapshots (utile pour les sauvegardes stables, sans demander d'interruptions) , et de l'agrandir à la volée en cas de besoin.
Bonjour,
Je serai intéressé par connaitre les moyens que tu utilises pour la conversion PDF et l'antivirus.
Pour le stockage, utilises tu un éclatement des fichiers sur plusieurs répertoires ? A ton avis est ce nécessaire en cas de gros volumes ?
L'idée d'utiliser un nom de fichier indépendant du nom initial me semble très bien. As tu un moyen de transférer le fichier avec le nom originel (rewrite ?) ?
Je serai intéressé par connaitre les moyens que tu utilises pour la conversion PDF et l'antivirus.
Pour le stockage, utilises tu un éclatement des fichiers sur plusieurs répertoires ? A ton avis est ce nécessaire en cas de gros volumes ?
L'idée d'utiliser un nom de fichier indépendant du nom initial me semble très bien. As tu un moyen de transférer le fichier avec le nom originel (rewrite ?) ?
Bien sur: pour la conversion, il s'agit d'open office qui tourne en mode "serveur", conjointement avec un petit script python qui facilite l'utilisation de la chose.Bonjour,
Je serai intéressé par connaitre les moyens que tu utilises pour la conversion PDF et l'antivirus.
Je viens de trouver un lien qui présente mieux la chose:
http://www.metal3d.org/index.php/blog/t ... de-serveur
Pour ce qui est de la vérification antivirus, il s'agit de ClamAV.
Note que tout ceci tourne sur un serveur dédié, hors de question d'arriver à ceci sur du mutualisé
Je me souviens de Youtube qui stockait un temps tous ses thumbnails dans un même répertoire. Après quelques dizaines de dizaines de milliers, ça commençait à devenir lent..Pour le stockage, utilises tu un éclatement des fichiers sur plusieurs répertoires ? A ton avis est ce nécessaire en cas de gros volumes ?
(mais il faut quand même un tas de fichiers pour avoir un impact sur l'accès au fichier - je ne parle pas du temps qu'il faut pour générer un aperçu du répertoire, celui-ci sera impacté bien avant).Dans mon cas, chaque fichier fait partie d'une sous-catégorie qui fait partie d'un catégorie. L'arborescence reflète simplement cet état. C'est simple, c'est KISS.
Le nom donné en interne au fichier (pour stockage) n'est jamais visible de l'extérieur: vis-à-vis de l'extérieur, ce dernier n'a jamais changé de nom. Tout est stocké en base de données: le fichier ne sert qu'à stocker les données brutes, qui ne rentrent pas dans la base de données (et pour cause, le système de fichiers est une base de données parfaite pour les fichiers - mais par pour des données).L'idée d'utiliser un nom de fichier indépendant du nom initial me semble très bien. As tu un moyen de transférer le fichier avec le nom originel (rewrite ?) ?
L'accès au fichier se fait par un script (caché par rewrite par exemple), qui récupère les données relatives au fichier dans la base de données, récupère les données brutes depuis le système de fichier, et rassemble le tout dans sa réponse: le visiteur ne voit jamais que tout à été décomposé, et il n'est pas censé le voir. S'il aime mettre des espaces, des accents et autres, c'est son problème, mais au moins ça ne se répercute pas dans le système.