Modèle des fichiers joints #61
No reviewers
Labels
No Label
Core
bug
duplicate
easy
enhancement
help wanted
invalid
performance
proposal
question
security
warning
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: devs/PCv5#61
Loading…
Reference in New Issue
No description provided.
Delete Branch "Filoji/PCv5:dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Euh ? C'est comme ça ? Sinon, voici attachement.py
Quelques remarques :
bytes()
?self.hash_file
et pashash_file
Les fichiers joints on les lie uniquement à des commentaires et pas à des posts ? Certainement les mécanismes vont s'appliquer aussi aux téléchargements de programmes et aux pièces jointes de tutoriels. On les considère comme les fichiers joints du top comment ? Comment on étend ça au stockage partagé des admins (la généralisation de l'adimg actuelle) ?
@Darks Opinion désirée.
devto Modèle des fichiers joints@Lephenixnoir : Le hash du fichier sert à renommer le fichier, mais ça je pense que tu le sais déjà. Ainsi, pour éviter les conversions inutiles, je préférais le stocker en temps que
str
pour ne pas se compliquer la tâche.En effet, @Darks m'a dit qu'il fallait joindre les attachment aux commentaires, et les top commentaires. Pour ce qui est du stockage partagé des admins, il ne m'en a pas parlé, mais on peut toujours faire une fonction (pas dans attachment) qui détectera de quel image on parle. Ainsi, on liera le commentaire à l'attachment précis déjà créé.
Pour le renommage je présume qu'il serait plus malin d'avoir un dossier du type
<hash>/<fichier>
, de sorte que le fichier se fasse télécharger sous son nom original tout en étant servi par Nginx sans demander de passer par la bdd ?Quelques remarques de mon coté
hashed
→hash
. Pourquoi se faire chier ? Un hash c'est unhash
😛hash/file
me parait intéressanteurl
(@property
) pour récupérer l'URL du fichierConcernant l'architecture, j'ai pensé associer les fichiers qu'à des commentaires. En effet, vu l'organisation actuelle des contenus (MainPost <> Thread <> (Top)Comment), je ne vois pas les cas de figure pour lesquels ont aurait envie d'attacher des PJ à un MainPost. Pour ce qui est de l'affichage des programmes par exemple, on liste les fichiers disponibles dans le top comment du programme, et suivant le type de fichier on l'affiche différemment (images, programmes, documentation, etc.).
Ce système me parait plus souple (on garde l'historique des versions de programmes dans les commentaires), plus facile à utiliser pour tout le monde, et plus facile à gérer au niveau du code.
Je ne vois pas le problème étant donné que le serveur web décide de la façon de servir les fichiers selon leur extension, et que l'OS de l'utilisateur qui télécharge un fichier va faire pareil.
Pour moi ça ne sert que si tu veux afficher le contenu d'un g1m ou une fonctionnalité nouvelle du genre.
Si je ne me trompe pas en disant MainPost = Program/Tutorial/Topic, alors on a une raison simple de vouloir mettre des PJ : fournir les fichiers en téléchargement au programme. Tu peux dire "les fichiers du top comment d'un programme sont les fichiers en téléchargement", auquel cas ok, et les anciennes versions des programmes resteront disponibles en téléchargement lorsque la description sera réécrite. Mais les autres métadonnées comme l'image, le numéro de version, la taille ou la catégorie ne le seront pas, ce qui fait un peu bizarre.
C'est ce à quoi je pense. La description d'un programme, c'est le top comment du thread associé. C'est plus cohérent avec le fonctionnement du forum (et donc plus simple quand il s'agira de migrer un topic vers un programme.
Pour l'image, je pensais chercher les images en PJ du top comment. Par contre pour la taille, le numéro de version et la catégorie, on n'aura pas l'historique. J'aurais tendance à dire que ce n'est pas critique.
Le but étant de traiter les fichiers selon leurs types, je voudrais être sûr qu'on puisse pas exécuter du Js parce qu'on a uploadé un fichier
.png
crafté. De même on peut vouloir générer des aperçus avec PIL, donc à voir comment on sécurise le bouzin. Si tu penses que se baser uniquement sur l'extension et des exceptions bien gérées est suffisant, soit.––– Edit –––
Ça se base pas sur le type MIME justement ? Anyway…
Ça pourrait me convenir mais j'ai quand même des doutes. Tu vois, ça me paraîtrait normal d'insérer des images supplémentaires dans la description ne serait-ce que parce que l'image de présentation est un GIF ou parce que les dimensions ne correspondent peut-être pas. Perso j'aimerais bien faire ça dans mes propres programmes.
Dans ce cas, la "détection" de l'image de présentation paraît pas évidente. Tu peux dire "c'est la première", auquel cas il faut les ordonner. Tu peux ajouter une métadonnée au programme avec la référence à l'Attachment associé, dans ce cas c'est perdu quand on réécrit la description (ce qui n'est pas grave, la référence à l'Attachment me dérange plus TBH).
Oui en fait je te rejoins là-dessus, la taille ça devrait être automatique, la version il suffit de compter le nombre de PP (dans le Thread ?), et la catégorie on s'en fout. Les notes, progrank, etc, pareil. Faut juste s'en souvenir pour faire prendre des mauvaises surprises je suppose.
Si l'extension est
.png
, le logiciel qui l'ouvre ne peut pas savoir que c'est du JS (en plus s'il y a suffisamment peu de code ça pourrait être du Python) et encore moins l'exécuter. Je pense que c'est pas plus dangereux que tout le reste du web, donc disons au moins suffisant dans un premier temps.Dès qu'il y a des fonctionnalité supplémentaires (eg. aperçus), c'est une autre affaire on est bien d'accord. Mais pour le reste je pense qu'il est suffisant de filtrer par extension.
J'ai l'impression que tu pars du principe qu'un programme ne peut avoir qu'une image de présentation.
J'avais plutôt en tête une galerie d'images associée au programme (comme sur les stores d'app par exemple). Pour ce qui est de l'image de présentation dans la liste des programmes, je vois plusieurs solutions :
Program
L'option 1 est la plus simple à mettre en place mais n'est pas satisfaisante pour les auteurs de programmes.
L'option 2 ajoute un peu de complexité, mais reste facilement implémentable. En plus ça peut s'appliquer de manière élégante au news (si on affiche un résumé en page d'accueil, on peut récupérer l'image principale via ce même flag).
L'option 3 est assez élégante, mais c'est un joli défi technique pour avoir un procédé fiable (qu'est-ce qu'on fait si on mélange un png avec un gif ?)
L'option 4 est la plus triviale, mais ne permet pas la mise à jour automatique du programme lorsqu'un nouveau top comment est choisi.
–––
Personnellement je préfère l'option 2, parce qu'elle est réutilisable ailleurs de manère élégante.
C'est vrai, je supposais ça. Je propose la solution 2 aussi, parce que comme ça on peut avoir des images dans la description sans les avoir dans la présentation (et inversement). Et on peut toujours faire le GIF à la main avant.
Dans ce cas est-ce qu'il ne faudrait pas structurer un peu les fichiers joints ? Au moins pouvoir donner un ordre aux fichiers en téléchargement me paraît le minimum. Dans ce cas je pense qu'Attachment a besoin d'un peu plus d'infos (catégoriser images/téléchargements, ordonner, etc).
Catégorie
On doit pouvoir se baser sur le type de fichier (donc l'extension) pour savoir si on affiche l'image, propose le fichier au téléchargement, voir même propose une preview du code. Pas besoin selon moi d'ajouter une métadonnée supplémentaire à ce niveau là.
Ceci dit ça n'empêche pas de stocker l'extension en bdd pour optimiser les opérations dessus.
Priorité
On peut se débrouiller pour stocker un entier
priority
dans avec chaque fichier. À l'affichage, on trie par priorité. Si deux fichiers du même commentaire on la même priorité, alors l'ordre est indéfini entre les deux.Exemple
Je poste un programme, dont le top comment contient ces fichiers :
On affiche alors :
mono.g1a
,color.g3a
,tutorial.md
,license.md
.image.gif
,menu.png
,jeu.png
Ce qui n'empêche d'ailleurs pas de réutiliser les images avec la balise image pour les inclure dans le corps du message.
Et dans la liste des programmes, on utilise l'image
image.gif
car c'est le fichier qui 1. est une image 2. a la plus haute prioritéMais ça ne te permet pas forcément d'avoir une image en fichier joint d'un tutoriel, alors que par exemple tu peux vouloir fournir un asset pour ajouter à un un add-in. Je pense que tu vois à quel point c'est inflexible.
Pourquoi pas simplement faire des PJ une liste (donc ordonnée) ? Ça me paraît beaucoup plus naturel. Il suffit que le formulaire où tu indiques les PJs les mentionne dans un ordre précis.
Hmm. Essayons ceci :
[télécharger](lien)
ou afficher une image![alt](lien)
même si le lien pointe vers le même fichierDans tous les cas au niveau du serveur web, il faut que tous les fichiers soient servis téléchargés, sinon ça veut dire proxifier les requêtes vers ceux-ci dans Flask. Et ça on était moyen chaud.
Parce que c'est beaucoup plus simple de gérer un entier qu'une liste ordonnée, tant au niveau du back que du front. Après le concept de liste me dérange pas, c'est juste que faire un formulaire pour ordonner des choix, c'est (très) relou soit pour le programmeur, soit pour l'utilisateur, soit les deux en même temps. Et encore plus si on se contraint à être fonctionnel même sans Js. KISS.
... Je sais pas, pour être honnête. J'ai l'impression qu'on invente des automatismes pétés pour rien parce qu'une fois sur 3 ça fera pas ce qu'on veut. Dans ma description de jeu je voudrais mettre des petites images ou des GIFs pour montrer un peu le gameplay, mais elles ne sont pas à télécharger, elles ne sont pas dans la présentation du programme, et ça ne sert à rien de les voir en bas (pas plus que ça ne sert de voir les images embedded dans un mail HTML en PJ).
Pourquoi ne pas contrôler tout ça proprement dans le modèle et laisser l'utilisateur faire quitte à mettre des défauts utiles ? Y'a pas des milliers de paramètres non plus.
Je pense que ça tout montre de toute façon que le modèle de la PJ toute seule n'est pas suffisant pour les besoins des programmes et tutoriels. Et j'ajouterai que je ne le pense pas suffisant non plus pour la gestion des fichiers partagés style adimg. Donc j'ai peu d'espoir de laisser le modèle comme ça et filer.
Désolé de prolonger la discussion mais y'a trop d'angles à arrondir pour que je soit vraiment confiant avec ces choix-ci.
Absolument, mais depuis quand on sacrifie la fonctionnalité pour le besoin de trivialiser l'implémentation ? Tu as omis de citer la perception de l'utilisateur lambda là-dedans qui n'a aucune idée de ce que la "priorité" va être. Faire une liste ce n'est pas seulement une question de fonctionnalité mais aussi une question de bonne GUI.
Et un flag
hidden
? Si c'est hidden on l'affiche pas en bas. Le reste ne changerai pas par rapport à ma proposition.Je ne suis pas sûr de la pertinence des fichiers
adimg
dans la v5. Enfin… On peut toujours reproduire le concept sur une partie dédiée, je ne suis pas sûr que le modèle Attachment s'y appliquera quoi qu'il arrive.Vaut mieux la prolonger maintenant qu'une fois que ce sera implémenté… :-°
Dans ce cas ok, mais tu t'occupe de la réalisation d'un formulaire facile à utiliser, avec un minimum de Js.
C'est un bon progrès ; je ne vois pas de cas particulier que cette proposition amendée ne gère pas (même si je parie qu'il en apparaîtra).
L'idée que les pages de programmes ne gèrent pas mieux les fichiers que les messages quelconques me gêne un peu en fait. J'ai un peu peur que les versions successives arrivent dans les commentaires et que la description du programme soit délaissée pour faire un gros topic en rolling release par flemme. Y'a pas ce risque dans la v42.
Pareil pour les abus dans les commentaires si c'est aussi puissant que ça, par exemple les limites de nombre et tailles de fichiers devraient pas être les mêmes entre les téléchargements d'un programme et les commentaires normaux. Mais si on archive tous les dls dans les commentaires on peut bypass ça et poser des problèmes de stockage en toute bonne foi.
(Quelque part c'est un peu l'extension de refuser les pièces jointes dans les MP, bien que moins extrême.)
Et pour revenir à la pertinence d'adimg et affiliés, on a bien besoin d'une façon de stocker des fichiers qui ne soit pas juste dans des commentaires. Il y a notamment des fichiers "statiques" comme les guides en PDF, des images partagées un peu partout comme la coupe du JDM, et j'aimerais accessoirement qu'on puisse "archiver" quelques fichiers comme des vieux manuels et autres raretés qui se perdent souvent avec le temps.
Bref, je vois vraiment pas comment on peut s'en tirer honorablement avec un seul niveau de traitement des fichiers. >_o
J'apprécie l'edit, j'avais des idées pour une version avec absolument zéro JS mais il fallait interagir avec le serveur beaucoup plus souvent. J'ai des idées mais on en reparlera quand on sera d'accord sur le modèle je suppose.
Si tu as une propal qui prends en compte tout les cas de figure, tout en étant assez permissive mais pas trop chiante à maintenir, vas-y hein… x)
Dans tous les cas il faudra bien que les versions successives arrivent dans les commentaires. Je trouverai ça dommage d'en perdre le fil. Surtout que ça rentre pile dans le cas du commentaire qui n'est pas raccord avec le top comment. ("Oh génial, par contre la boule bouge bizarrement — J'ai udpate le programme en remplaçant la boule par un cube")
Là je suis pas d'accord. Pourquoi un commentaire construit sur un topic présentant l'avancement d'un projet imposant ne pourrait pas bénéficiers d'autant de place qu'un programme ? Si on fait ça on va repartir dans le mode v42, postant plusieurs messages pour héberger plusieurs images.
J'aurai tendance à dire qu'on ne devrait pas limiter les PJ à priori mais à postériori (avec la page d'admin qui va bien). Qu'on autorise ou non les PJ dans les MP d'ailleurs.
Ok, mais ça nécessite une app de stockage de fichiers, donc c'est un peu hors-sujet, ici on traite des pièces-jointes des commentaires, et par extension – si on s'accorde pas sur un autre modèle – des programmes, tutoriels et autres.
Il est vrai que j'ai pas pensé au problèmes du nombre de téléchargements, etc. Si tu as autre chose de plus polyvalent et qui sera pas trop usine à gaz, à voir…
Disons que pour ce qui est des programmes/tutoriels/etc je pense qu'il est élégant d'ajouter des propriétés dans le modèle pour laisser de latitude à l'utilisateur plutôt que de tout faire en automatique. D'ailleurs on est tombés sur ça au moins deux fois : pour la sélection de l'image de présentation d'un programme et pour les fichiers cachés par défaut.
J'ai eu un peu l'impression que ça te dérangeait notamment quand tu as dit ça, ce qui ne me paraît pas vraiment naturel.
Ça pose quand même un léger problème de stockage (ce que je n'ai pas réalisé tout de suite). Les plus gros projets sont aussi ceux qui sont modifiés le plus, et un add-in Prizm ça fait vite 2 Mo par fichier par version.
Personnellement ça ne me paraît pas abusif d'archiver ainsi les versions de programmes, mais pour les commentaires génériques je suis convaincu qu'il faut des limites plus strictes. Par exemple les logiciels actuels font jusqu'à plus de 50 Mo (ClassPad Manager). Tu peux clairement pas te permettre de mettre cette limite partout dans les commentaires d'un topic random, ça poserait autant de problèmes d'abus sur le stockage que sur la taille des requêtes et la bande passante du serveur.
Bien sûr, quand l'auteur d'un projet poste des updates sur ce projet, pas de raison de se priver. Mais ce n'est pas le commentaire random d'un invité qui poste sur un topic qu'il n'a jamais lu, cas qui dans ta proposition autorise les mêmes limites.
Mon intuition est d'autoriser un stockage conséquent pour le topic au lieu de ses commentaires, ce qui permet à l'auteur de faire ce qu'il veut sans pour autant ouvrir la porte à toutes les dérives.
Pour ce qui est des archives d'anciens post principaux, on les comptabiliserait alors simplement dans les limites du topic/programme sans appliquer les limites plus restrictives que je propose sur les commentaires quelconques. En outre, cela résoud le risque que j'avais évoqué que les versions soient publiées juste en commentaire car les gros fichiers ne peuvent être ajoutés que si un nouveau post principal est écrit.
Je décèle une pente glissante ici, tu sais bien que je considère cette limite de la v42 comme un problème et que je ne proposerais pas un système qui nous oblige à faire ça.
Je garde bien ça à l'oeil, mais outre les enjeux de PJ dans les MP qui posent des questions de confidentialité, il reste le problème de la bande passante et de la réactivité du serveur qui peut en prendre un coup.
Je voyais quelque chose d'un peu plus simple qu'une appli complète, mais certes. C'est pas des fichiers joints, mais comme le code de Filoji traite un peu de tous les fichiers uploadés je pense que le sujet va revenir vite et/ou que le code va être dupliqué à ce moment-là, donc je l'évoque dès maintenant.
Ça ne me dérange pas de stocker ça dans les métadonnées du programme, mais ça ajoute de la spécificité aux programmes/tutos, alors qu'en soit les topics fonctionnent pareil, au moins pour les news.
Empêchant d'autres membres de faire des retours complets sur un autre projet… Empêchant aussi l'auteur d'un topic de 50 pages et 40 updates d'ajouter encore plus de contenu.
Je serais plus partant pour une limitation par type de membre plus que par contexte. Drastique pour les invités, un peu plus légère pour les membres, assez large pour les membres+, et illimité pour le reste.
Sachant que quoi qu'il arrive la limite pête en postant plusieurs messages… Chose qui arrivera si les limites ne couvrent pas les usages légitimes. Cf l'addendum de ce message.
Et écrire un nouveau post principal, c'est écrire un nouveau commentaire. Ou alors le modèle
MainPost <> Thread <> TopComment
n'est pas adapté. Ce que je trouve dommage parce qu'il répond à beaucoup de problèmes d'un coup, en particulier l'historique des conversations.On peut modérer les PJ sans en avoir le contenu. Le poids, la quantité et la fréquence peut être suffisant. À voir, même si j'ai pas d'avis sur autoriser ou non les PJ dans les MP.
De toute façon les MP n'ont pas pour vocation d'être 100% confidentiels. C'est un outil mis à disposition pour échanger rapidement entre deux membres. Pour le reste, c'est à eux de se mettre d'accord sur un moyen d'échange approprié.
La classe
Attachment
n'est peut-être pas adaptée dans ce cas. On peut la renommer enFile
si tu veux. Mais bon, je vois pas comment tu veux gérer l'hébergement des fichiers admin sur le même modèle que le reste.Je pense qu'un bon panel admin de gestion des fichiers pour modérer les abus sera plus efficace que d'essayer de les limiter à priori, avec les conséquences que ça peut avoir quand on aura des utilisateurs cherchant à les contourner. On peut leurrer un programme, un admin c'est plus compliqué. 😉
De manière générale le stockage des PJ va obligatoirement bouffer par mal de place. Aujourd'hui on ne le voit pas parce que 95% des images sont stockées ailleurs. J'espère qu'à terme on n'arrivera plus à tout mettre sur le VPS, car l'inverse voudrait dire restreindre des usages légitimes. Et ça ne me fait pas du tout peur d'envisager un moyen de stockage dédié (et adapté) aux fichiers du site.
Hmm d'accord, je pense que je peux me ranger sur l'usage d'un système identique pour la modération des contenus et les commentaires. Avec les points importants suivants :
Je souhaiterais seulement revenir sur le traitement qui est fait de ces fichiers. Je pense qu'un peu de flexibilité serait bienvenue pour accomplir les tâches "élaborées" que les contenus réservent au fichier joints. En particulier...
Les détails seraient certainement à fixer ; ici je défends seulement l'attitude d'ajouter des propriétés aux Attachment ou aux MainPost qui les référencent pour gérer ces fonctionnalités-là en donnant le contrôle à l'utilisateur, plutôt que de partir du principe qu'une preview des fichiers dont le nom laisse entendre que c'est des images suffira.
Je te rejoins, d'où la proposition de mon modèle (ordre + hidden) qui répond parfaitement à tout ça.
hidden
, même si je ne vois pas de cas légitime où on ne voudrait pas de la table des figuresLe cas du tuto, j'aurais tendance à générer le PDF nous-même. Sinon c'est relou pour l'utilisateur d'avoir à mettre à jour son tuto plus le PDF si il corrige une coquille. Sans parler de l'uniformité des templates, mais ça c'est annexe.
Les autres cas de figure, on les gère aussi : la banque de sprites ? On met dans une galerie les fichiers images, on affiche en bas les
.xcf
et les liens de téléchargement. Tu veux pouvoir mettre des images dans une news et définir une image principale pour le partage sur les réseaux sociaux ? Tu prends la première image en PJ. Etc. Tu veux pouvoir vérifier qu'il n'y a pas eu trop d'abus ces derniers temps ?/admin/fichiers
, tu affiche un tableau avec l'origine, l'auteur, la date et la taille desAttachments
, de quoi les supprimer facilement si besoin.Non clairement je trouve ce système fiable, robuste, et suffisament évolutif pour qu'il soit implémenté.
Je suis prêt à accepter le flag
hidden
même si je ne vois pas pourquoi on voudrait cacher des fichiers de la table des figures.On va y arriver !
Euh... je suis pas chaud pour avoir LaTeX sur le VPS surtout avec tous les modules classiques qui nécessite
-shell-escape
(eg.minted
). Oublie pas qu'on avait ça dans le viseur.Et... tout dans l'usage des fichiers pour les MainPost est plus subtil que ce que tu présentes.
Tout le monde n'utilise pas Gimp/Photoshop, les PNG sont souvent les images de travail. Donc tu traites pas pareil les images sources PNG et les images sources XCF - problème de sémantique. Tu es incapable de distinguer un PNG de preview où je présente une map d'exemple du PNG de mon tileset qui est le véritable asset. C'est bâclé !
Justement non c'est ce raisonnement qui est le problème ! Non, si tu veux mettre une image de présentation d'une news qui part sur les réseaux sociaux, tu mets un attribut dans Topic pour définir quel fichier joint est cette image. Et je te rappelle qu'il n'y a pas d'ordre sur ces fichiers dans le modèle que tu défends ! (Et pas non plus dans ce que je propose ci-dessous)
Pourquoi vouloir hacker sans cesse avec des cas particuliers, des traitements par extension pour la visualisation et des premiers touts ? Puisque tu laisses l'utilisateur uploader les fichiers, laisse-lui dire comment ces fichiers doivent être traités !
Proposition pour le gestion des MainPost, incluant les photos de présentation/réseaux sociaux, l'ordre des fichiers à télécharger, les PDF principaux de tutoriels, etc :
Va pour ton modèle. Je note que tu oublie l'idée d'ordonner les téléchargements, très bien.
Pour le reste (faire une galerie auto par exemple), on peut se démerder.
Et je viens de me dire. Si on proxifie pas les reqûetes d'une manière ou d'une autre, on ne peut pas tracer le nombre de téléchargements sans parser les logs de connexion. À la rigeur on peut ajouter une route qui compte les téléchargements du fichier et retourne une 302 vers le fichier statique. Ça ne comptabilisera que les téléchargements via le lien de redirection, mais c'est déjà ça.
Merci de m'avoir rejoint ici. Je pense aussi que c'est plus élégant si on peut éviter l'ordre.
Hmm j'ai cherché un moyen de faire ça avec Nginx, je pense avoir trouvé un bon compromis. Ce qu'on peut faire c'est utiliser le module
mirror
pour émettre une sorte de requête miroir purement interne après avoir envoyé le fichier au client. Donc le client obtient le fichier sans le surcoût de la redirection et sans le surcoût du passage à Flask.Et ensuite dans Flask :
Les avantages donc c'est que Nginx sert le fichier de façon transparente pour l'utilisateur sans redirection, avant d'émettre la requête miroir ; et il ignore la réponse à la requête miroir, donc la connexion HTTP n'est pas maintenue.