Le 2004-09-16, à 17:27:04 +0200, Antoine (antoine@pitrou.net) écrit:
Tu veux dire que ça ne marchera nulle part, sauf chez ceux qui ont le
moyen de se payer un serveur dédié.
Un de nos sites est hébergé sur un serveur typique bon marché.
Ils ont ni antiword ni wvText, par contre ils ont pdf2ps et
ps2ascii. Le serveur semble être un FreeBSD 4.9 ordinaire.
À mon avis c'est un peu comme les bidules GD pour les vignettes:
c'est très pratique mais c'est pas toujours supporté. Mais après
quelques bidouilles avec le temps et un peu de pression au près
de son hébergeur préféré, ça devient fiable et universel pour Joe
l'utilisateur moyen.
Ca ne serait pas compliqué à modifier pour quelqu'un qui voudrait vraiment
le faire :
* une RewriteRule qui passe tous les documents à protéger à un script
RewriteRule IMG/pdf/ securedoc.php
* un script qui checke le caractère protégé du doc et le statut du visiteur,
et renvoie ou non le doc.
J'avais commencé à le faire il y a un bout de temps, puis arrêté car pas
trop motivé. Le script ci-joint, à mettre à la racine du SPIP, s'occupe
de la partie HTTP et redirections (le .htaccess à créer dans le
répertoire IMG est indiqué en commentaire au début du script).
Quelques points très importants :
- il ne faut pas rediriger tous les types de documents ; notamment, si
on redirige les images, chaque affichage d'image dans un article fait
appel au script de validation ce qui écroule les performances et embête
prodigieusement le visiteur du site
- il faut renseigner les mime-types dans la table spip_types_documents
(ou ailleurs) pour renvoyer le bon Content-Type (ce n'est pas fait dans
le script ci-joint)
Ensuite chaque webmestre pourra triturer le script pour appliquer les
restrictions qu'il souhaite.
L'avantage de cette solution, c'est qu'elle est invisible : le visiteur
voit bien une URL de document normale, pas un affreux bidule à la
"download.php?id=1257".
(pour vérifier que la redirection marche, affichez les en-têtes renvoyés
par le serveur quand vous récupérez un document, et vérifiez qu'il y a
bien "X-Powered-By: PHP/quelque chose")
> Vraiment pas un vrai moteur d'indexation libre qui ne necessite pas un
> monstre comme serveur ?
Tu as déjà la réponse : SPIP.
je voulais dire qui indexe les documents word et pdf ...
Ceux qui ont deja utilisé Lucene auront compris.
> Est-ce que l'utilisation de Perl est un probleme ?
Si tu trouves un autre environnement qui est aussi répandu que PHP chez
les hébergeurs bon marché, tu peux proposer
La question etait : est ce que les hebergeurs gratos autorisent
l'utilisation de script perl, je pense qu'il y a plus de chances de trouver
notre bonheur de ce coté ...
Je n'ai pas proposé une autre solution qui me semble techniquement jouable :
utiliser Lucene depuis une classe PHP
Le probleme c'est qu'il faut que java soit activé dans la config PHP et ca,
c'est moins courant.
PS : pour la protection de /IMG, j'avais aussi fait un script, meme
pb/remarque : penser à exclure ce qui n'est pas à proteger.
J'ai utilisé un wrapper de PHPClasse (downloadfile.class) qui s'en sort pas
mal avec les types mime.
La question etait : est ce que les hebergeurs gratos autorisent
l'utilisation de script perl, je pense qu'il y a plus de chances de trouver
notre bonheur de ce coté ...
La mise à disposition de perl n'est pas forcément universelle. Sur Sivit (http://www.sivit.fr/) par ex, perl n'est pas autorisé. Donc même en mutualisé, la mise à disposition de perl n'est pas évidente... :-/
Je ne crains qu'il faille rester dans des scripts utilisant des configurations classiques... :-/