Author: cedric@yterium.com
Date: 2009-04-28 19:02:21 +0200 (mar, 28 avr 2009)
New Revision: 13930
Log:
retablir un content-type indument supprime par [13924]
Modified:
branches/spip-2.0/ecrire/action/acceder_document.php
Le 28 avr. 09 à 19:02, cedric@yterium.com a écrit :
Author: cedric@yterium.com
Date: 2009-04-28 19:02:21 +0200 (mar, 28 avr 2009)
New Revision: 13930Log:
retablir un content-type indument supprime par [13924]
Ben non, dans http://trac.rezo.net/trac/spip/changeset/13927
on voit que
header('Content-Type: application/octet-stream');
était mis en commentaire, aussi bien dans la branche dev que dans la stable.
Il faut alors être plus strict que cela :
- vérifier que l'extension est bien la bonne
Ca veut dire quoi la bonne ?
Moi je veux pouvoir faire ça:
- renommer localement un fichier truc.php en truc.txt pour pouvoir le mettre en doc attaché sous SPIP
- dire que son titre est truc.php
- et acceder_document le creer localement chez celui qui le charge sous le nom truc.php
- vérifier que le titre ne comporte pas de caractères interdits dans les nom de fichiers (:,/\<>)
a la rigueur, mais Unix ne l'interdit pas, pourquoi SPIP l'interdirait ?
....
Je viens de voir http://trac.rezo.net/trac/spip/changeset/13931
tu pourrais attendre que je réponde à tes mails.
---> revert, pour la raison que je viens d'exposer.
Committo,Ergo:Sum
Le 28 avr. 09 à 20:59, Emmanuel Saint-James a écrit :
Le 28 avr. 09 à 19:02, cedric@yterium.com a écrit :
Author: cedric@yterium.com
Date: 2009-04-28 19:02:21 +0200 (mar, 28 avr 2009)
New Revision: 13930Log:
retablir un content-type indument supprime par [13924]Ben non, dans http://trac.rezo.net/trac/spip/changeset/13927
on voit que
header('Content-Type: application/octet-stream');
était mis en commentaire, aussi bien dans la branche dev que dans la stable.
oui justement, par 13924, et c'était une erreur de ma part, dont je me suis aperçu en lisant ton commit.
Il faut alors être plus strict que cela :
- vérifier que l'extension est bien la bonne
Ca veut dire quoi la bonne ?
Moi je veux pouvoir faire ça:- renommer localement un fichier truc.php en truc.txt pour pouvoir le mettre en doc attaché sous SPIP
- dire que son titre est truc.php
- et acceder_document le créer localement chez celui qui le charge sous le nom truc.php
ok, le problème est que toi tu veux pouvoir faire ça, et que le faisant tu sais ce que tu fais en ne mettant pas n'importe quoi dans le titre.
Mais du coup, c'est une fonctionnalité cachée dont l'utilisateur standard n'a aucune conscience, avec le risque de mettre n'importe quoi dans le titre qui ressemble à un nom de fichier, et qui rend alors le fichier téléchargé inutilisable pour les internautes.
Le problème d'introduire des fonctionnalités cachées de ce type est que cela génère des bugs apparents lorsque les utilisateurs tombent sur ce fonctionnement par hasard.
Je pense que ton besoin n'a rien de générique, mais est au contraire tout ce qu'il y a de particulier, propre à ton utilisation de SPIP, puisqu'il ne s'agit plus seulement de servir le fichier avec une protection, mais de faire de la réécriture de nom, et même de type, de ce que je comprends de ton exemple.
La question sous-jacente est donc de savoir si le core doit traiter des cas particuliers à coup de hack, avec les problèmes que cela entraîne par la suite.
Je rétablis dans le core la possibilité d'envoyer une autre extension, mais comme je pense que c'est plus un risque de bug qu'autre chose, je mets la version sécurisée dans le plugin accès restreint.
Cela dit je pense que ça devrait être le contraire : une version sans risque de bug dans le core, et une version spécifique pour les applications qui veulent faire autre chose.
- vérifier que le titre ne comporte pas de caractères interdits dans les nom de fichiers (:,/\<>)
a la rigueur, mais Unix ne l'interdit pas, pourquoi SPIP l'interdirait ?
pour éviter d'envoyer n'importe quoi aux internautes qui ne sont pas sous unix, et pour limiter au maximum le risque que spip considère comme nom de fichier quelque chose que le webmestre considérait comme un simple titre.
Cédric
Le 28 avr. 09 à 22:57, cedric.morin@yterium.com a écrit :
c'est une fonctionnalité cachée dont l'utilisateur standard n'a aucune conscience,
La doc devrait le dire, je suis d'accord.
avec le risque de mettre n'importe quoi dans le titre qui ressemble à un nom de fichier, et qui rend alors le fichier téléchargé inutilisable pour les internautes.
Du moment qu'il y a une extension il est utilisable, sans parler des portes de sorties ctrl+click pour forcer un menu de choix d'appli d'ouverture du document.
Je pense que ton besoin n'a rien de générique,
Je ne suis pas d'accord: l'existence de l'en-tête Content-Disposition prouve que justement ce besoin a été perçu par les concepteurs de MIME, rien que ça.
Je rétablis dans le core la possibilité d'envoyer une autre extension,
Ok, merci. Je pense que pour gagner en généralité, en l'absence d'extension on pourrait rajouter au titre l'extension d'origine.
Utilité: je balance un jeu de photos nommé XX001.jpg, XX002.jpg etc, je mets des titres à chacune pour le diaporama ("crâne de Mozart à 5 ans" etc), et qui veut récupérer une des photos va recevoir "crâne de Mozart à 5 ans.jpg", ce serait mieux que XX001.jpg.
Committo,Ergo:Sum
Le 29 avr. 09 à 07:41, Committo,Ergo:sum a écrit :
Ok, merci. Je pense que pour gagner en généralité, en l'absence d'extension on pourrait rajouter au titre l'extension d'origine.
Utilité: je balance un jeu de photos nommé XX001.jpg, XX002.jpg etc, je mets des titres à chacune pour le diaporama ("crâne de Mozart à 5 ans" etc), et qui veut récupérer une des photos va recevoir "crâne de Mozart à 5 ans.jpg", ce serait mieux que XX001.jpg.
Bof bof. Franchement, je préfère récupérer le nom de fichier que j'ai utilisé à l'upload, que j'ai pu définir de manière précise pour le stockage, alors que le titre n'est que pour l'affichage.
-Nicolas
--
Nicolas HOIZEY
Le 30 avr. 09 à 07:57, Nicolas Hoizey a écrit :
Le 29 avr. 09 à 07:41, Committo,Ergo:sum a écrit :
Ok, merci. Je pense que pour gagner en généralité, en l'absence d'extension on pourrait rajouter au titre l'extension d'origine.
Utilité: je balance un jeu de photos nommé XX001.jpg, XX002.jpg etc, je mets des titres à chacune pour le diaporama ("crâne de Mozart à 5 ans" etc), et qui veut récupérer une des photos va recevoir "crâne de Mozart à 5 ans.jpg", ce serait mieux que XX001.jpg.Bof bof. Franchement, je préfère récupérer le nom de fichier que j'ai utilisé à l'upload, que j'ai pu définir de manière précise pour le stockage, alors que le titre n'est que pour l'affichage.
Je trouve effectivement qu'on mélange deux choses qui n'ont rien a voir, et que une telle fonctionnalité devrait dans ce cas être prise en charge par un champ spécifique 'nom du fichier' que l'on remplit, ou pas, en connaissance de cause, et indépendamment du titre du document tel que présenté en ligne.
Ce genre de hack est une plaie fonctionnelle que l'on traîne ensuite des années au prétexte que l'un ou l'autre l'utilise chez lui, alors qu'il est si simple d'ajouter un champ dédié, et que l'espace de stockage ne coûte rien.
(Il n'y a qu'à voir l'exemple des articles virtuels implémentés par une valeur spécifique du chapo ...)
Le vrai problème est ici que l'interface des documents est encore implémentée à l'ancienne, à coup de formulaires php cachés dans les recoins du core, et que l'ajout d'un champ implique le fork de N fichiers.
Il est temps de finir la ré-implémentation qui est en chantier dans la médiathèque (plugin gestion_document) et qui permettra la même souplesse sur la personnalisation de l'interface des documents que sur les autres objets
Cédric
Le 30 avr. 09 à 11:45, cedric.morin@yterium.com a écrit :
Ce genre de hack est une plaie fonctionnelle que l'on traîne ensuite des années au prétexte que l'un ou l'autre l'utilise chez lui, alors qu'il est si simple d'ajouter un champ dédié, et que l'espace de stockage ne coûte rien.
Il ne coute pas grand chose en terme de place, ok, mais augmenter le nombre de champs par table ne facilite pas la maintenance non plus: on ne va pas mettre en standard dans chaque table autant de champs que de plugins pouvant l'utiliser.
Le vrai problème est ici que l'interface des documents est encore implémentée à l'ancienne,
Ca je suis d'accord, mais tes modifs portaient à la fois sur la version de dev et sur la soi-disant stable, et en plus ils n'étaient même pas synchrones. A présent on a les 2 versions qui:
- font comme avant pour les documents avec titre ayant une extension
- repassent sur le nom du fichier quand le titre causait une apparence de bug dans un système d'exploitation neuneu.
Ca me semble un bon compromis pour la stable. Pour la dev, il faut repenser tout ça on en est tous d'accord depuis longtemps, mais que la stable mérite son nom de stable.
Committo,Ergo:Sum
Le 30 avril 2009 11:45, cedric.morin@yterium.com
<cedric.morin@yterium.com>a écrit :
Le 30 avr. 09 à 07:57, Nicolas Hoizey a écrit :....
Bof bof. Franchement, je préfère récupérer le nom de fichier que j'ai
utilisé à l'upload, que j'ai pu définir de manière précise pour le stockage,
alors que le titre n'est que pour l'affichage.Je trouve effectivement qu'on mélange deux choses qui n'ont rien a voir,
et que une telle fonctionnalité devrait dans ce cas être prise en charge par
un champ spécifique 'nom du fichier' que l'on remplit, ou pas, en
connaissance de cause, et indépendamment du titre du document tel que
présenté en ligne.
Je plussois, il faut tendre vers une clarté des spécifications du
fonctionnement, il me semble que c'est l'objectif de la v2.x d'avoir un
noyau simple.
------------------------------
Arnaud
Ce genre de hack est une plaie fonctionnelle que l'on traîne ensuite des
années au prétexte que l'un ou l'autre l'utilise chez lui, alors qu'il est
si simple d'ajouter un champ dédié, et que l'espace de stockage ne coûte
rien.
+1 : c'est vraiment l'affaire d'un plugin
-- Fil