Discussion :

[Dendrite]

Bonjour chers collègues virtuels,

Dans le cadre de mon métier, j'aimerais avoir votre retour d'expertise.

Vous vous doutez que j'ai déjà fait des formulaires d'upload pour un utilisateur.

1) Quelle est la meilleure façon de sécuriser ce type de formulaire ? Parce que là, vu la volumétrie (100 000 utilisateurs potentiels), je dois verrouiller façon Ceinture + Bretelles.

2) Côté serveur, est-ce que cela a une importance (en matière de volume dans l'espace stocké) la façon de ranger les fichiers ?

Exemple 1

appli / pj / 100 000 logins / une dizaine de fichiers.pdf

Exemple 2

appli / pj / 1 000 000 login_fichier1.pdf

3) Accessoirement, ou pas, il faut que je passe à Symfony en même temps... Faut bien y passer un jour.

J'attends vos retours...

[_Thomas]

Salut,

C'est plus une piste pour alimenter ta réflexion qu'un réel "retour d'expertise", mais j'ai suivi ce cours récemment (vidéos payantes mais scripts et extraits de code gratuits) : https://symfonycasts.com/screencast/symfony-uploads

Je trouve qu'il contient des exemples finalement très complets pour se rendre compte des problématiques qui se posent lorsqu'on doit gérer l'upload de fichiers (l'upload en lui-même, la validation, les utilisations possibles des fichiers uploadés, l'intérêt d'une couche d'abstraction, le stockage "dans le cloud", ...). Par contre effectivement c'est du Symfony !

[Dendrite]

Je te remercie de cette info. S'il s'avère que je dois absolument passer en Symfony dès cette appli, je serais même prête à payer, sur mes deniers, un petit peu pour me former.
A étudier donc !

Le cahier des charges s'est précisé, et en vitesse de croisière, on sera plus près de 20 000 utilisateurs que de 100 000 à tel jour j... ça change la donne.

[Invité]

Bonjour Dendrite,

pour l'upload,

• tu as :Outil d'upload AJAX-PHP (ABCIWEB)
• un exemple de traitement : 4-C3. Traitement Fichier : news_traiter_file.php (vérification extension, type mime,...) + configuration (extensions / types mime autorisés,...)

Pour le stockage :

• rien ne t'empêche d'avoir un dossier par client.
  C'est aussi plus facile à gérer : si le client s'en va, on supprime physiquement le dossier et tout ce qu'il contient.
• l'espace de stockage ne dépend pas du nombre de dossiers créés, mais du poids des fichiers stockés

[ABCIWEB]

J'attends vos retours...

Ce module d'upload donné en lien par jreaux62 gère les erreurs d'upload, ansi que les erreurs fatales avec un retour d'information configurable, les informations en temps réel, la fragmentation des fichiers qui permet de faire des sauvegardes temporaires et de s'affranchir des limitations serveur de php, etc. Les fichiers sont contrôlés avant leur transfert définitif dans le répertoire choisi.

Le contrôle ne vérifie actuellement que les extensions, je me suis limité à cela pour avoir un code au maximum générique exploitable directement sur tous les environnements car le fichiier "magic.mime" n'était pas toujours accessible (lors de mes tests) notamment sur un serveur local Wampserver, mais il est disponible chez les hébergeurs type OVH. Tu peux donc compléter le code côté serveur avec mime_content_type ou finfo_file pour vérifier le type mime en complément des extensions. N'oublies pas d'utiliser préalablement la méthode cleanFileName() pour nettoyer le nom du fichier, ou tu peux aussi le renommer en fonction du login etc, mais il ne faut pas utiliser le nom du fichier sans l'avoir contrôlé.

Une autre protection pour les images est d'utiliser la lib gd, si elle ne fonctionne pas, l'image est invalide. Le module d'upload utilise cette lib pour contrôler l'orientation des images, tu peux aussi utiliser les fonctions de redimensionnement fournies pour optimiser uniquement les images pour le web (sans nécessairement les redimensionner). Il est peu probable qu'un virus puisse se cacher dans les images sans provoquer de bug en utilisant ces fonctions. Voir les exemples de code côté serveur dans le dossier du module d'upload.

Concernant les fichiers pdf tu peux faire de même en essayant de les ouvrir avec un outil pdf comme PDF_open_pdi_document, mais il te faudra préalablement installer PECL pdflib. Sinon il existe d'autres solution comme FPDI ou encore pdfparser. J'aurais tendance à utiliser la lib php en priorité supposée plus sécuritaire, car un pirate vicieux pourrait inclure un pdf spécialement conçu pour exploiter des failles de ces lib... en imaginant le pire.

C'est tout ce que tu peux faire côté développement, après les serveurs ont aussi des systèmes de protection contre les virus, faut voir cela avec les admin serveurs.

Cela dit un fichier qui n'a pas la bonne extension ne pourra pas s'exécuter sur le serveur, il faudrait que le pirate puisse modifier l'extension après le téléchargement pour une utilisation directe si tu as vérifié l'extension lors du téléchargement. Tu peux aussi déplacer tes fichiers en dehors de l'arborescence de www si tu n'as pas besoin d'un accès direct via l'url. Mais le piratage provient le plus souvent de fichiers ajoutés par un logiciel tiers non sécurisé (type wordpress non mis à jour) situé sur le même serveur et qui peuvent écrire des fichiers dans les répertoires sans aucun contrôle préalable.

Après reste l'ouverture du fichier sur un poste client. Si toutes les précautions précédentes n'ont pas détectées le virus, tu te retrouves dans les mêmes conditions que lorsque tu tentes d'ouvrir un pdf sur internet, et là comme toujours il est conseillé/obligatoire d'avoir un antivirus et pare feu actif.

Je conseille de ne pas mettre plus de 100 000 fichiers dans le même répertoire, car si tu dois ensuite utiliser des fonctions php pour scanner le répertoire ça va finir par ramer ou au minimum prendre de plus en plus de temps. Mais cela dépend aussi de ton serveur, j'ai fait des tests en local avec un DD classique et non pas avec un SSD ce qui améliorerait considérablement les choses. Le scan du répertoire avec des fonctions php sera aussi notablement accéléré si tu ne mélanges pas des dossiers et des fichiers dans un même répertoire. Après si tu n'as pas besoin d'explorer le répertoire avec des fonctions php comme scandir ou autre, cela à moins d'importance, mais comme l'a dit jreaux62 des "petits" dossiers sont souvent plus facile à gérer.

Concernant le nombre d'upload simultanés, c'est indépendant du système d'upload mais dépend uniquement des capacités du serveur de même que le volume total.

Je ne pense pas que symfony soit indispensable, en tous cas pas pour l'upload lui-même car ce module d'upload par exemple est en téléchargement et éprouvé depuis de nombreuses années et je l'utilise personnellement sur mes sites sans que personne ne s'en soit jamais plaint. Donc celui là ou un autre , mais symfony n'est pas indispensable dans tous les cas.

Le seul intérêt que je verrais à utiliser synfony si tu ne l'utilise pas par ailleurs dans ton projet, est s'il implémente la validité des pdf avec le contrôle d'ouverture/validité dont je parlais plus haut, mais tu pourrais probablement faire l'équivalent avec les pistes que je t'ai données sans que cela ne te prenne beaucoup de temps si tu veux faire tous les contrôles possibles. Cela dit je n'en trouve pas la trace en consultant la doc symfony concernant l'upload des fichiers (je ne peux pas l'affirmer à 100% car je ne l'utilise pas). Apparemment comme tous les framework, ils utilisent le type mime en utilisant les fonctions natives de php puisque je vois en commentaire dans symfony/mime: "have you enable the php_fileinfo extension?".

[grunk]

Coté upload :
- Vérifier la taille du fichier
- Vérifier l'extension
- Vérifier le type mime (avec finfo)
- En fonction du type supposé ajouter des vérifications supplémentaires : Par exemple pour les images essayer de les retraiter (cherche sur le forum j'ai répondu à un truc du genre y'a pas longtemps). Pour les documents essayer de les réouvrir , etc ...
- Ne rien stocker dans un dossier accessible depuis le web.

Coté stockage :
Eviter de stocker trop de fichier par dossier. D'une part certains système on des limites et d'autres par tu risques de rendre le listing de fichier très compliqué.
Un système par utilisateur puis par date est en général pas mal.
Idem pour tes dossier contenant les 100K utilisateurs , on peut imaginer qu'il soit répartis par tranche de 1000 dans des sous dossier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
1-1000
    |_toto
    |_tit
1001-2000
    |_tutu

Ca aura le très gros avantage de rendre le fractionnement sur d'autres serveur/disque beaucoup plus facile. Ça risque d'être inévitable dans le temps.

[ABCIWEB]

Oui j'avais parlé d'un maximum de 100 000 mais c'était vraiment limite sur un DD classique, alors qu'avec 10 000 mon tri pour rapatrier une liste d'une centaine de fichiers prenait rarement plus d'une seconde (contre 6 à 8 pour les 100000) et c'était la limite haute que je m'étais fixée à l'époque. Si tu peux faire encore moins tu n'auras jamais de problèmes et des retours quasi instantanés en cas de listing.

J'avais remarqué aussi que les recherches gagnaient minimum 30% de performances en ne mélangeant pas dossiers et fichiers au même niveau d'un répertoire (les temps mentionnés plus haut étaient pour ce cas le plus favorable).

Pour ces tests j'utilisais la SPL et DirectoryIterator. Cela dit niveau performances pures ce n'était pas plus rapide que les fonctions basiques de php d'après mes bench.