Un ami me signale une problématique posée par la conception de spip,
rendant complexe la tâche de protéger des fichiers qu'on voudrait
attacher aux éléments d'un espace restreint. À l'heure actuelle ceux-ci
sont voués à rester accessibles à tout le monde, au moins abstraitement,
via leur chemin d'upload dans le répertoire /IMG
Si dans les évolutions futures de spip, un dispositif de protection de
tels fichiers était envisageable (des scripts php de certains wiki leurs
confèrent ce genre de verrouillage d'accès), quels seraient à votre avis
les moyens les plus légers et praticables :
- n'empêchant pas l'affichage et l'accès standard aux fichiers
non-protégés ;
- soumettant l'accès aux fichiers protégés à des critère d'authentification
...la solution devrait-elle passer, pour être gérable, par la génération
de sous-dossiers particuliers aux types mime utilisés ?
Je précise que c'est demandé dans un projet intégrant une sorte de
médiathèque devant rester privative.
Si des solutions combinées ont pu être déployées pour ce faire (c'est ce
vers quoi on s'achemine pour le moment), toute suggestion à cet égard
nous serait la bienvenue.
Merci.
Le plugin accès restreint propose une solution, fonctionnelle mais techniquement pas très satisfaisante.
Ce serait à réécrire à base de htaccess pour que l'url d'un document ne change pas selon qu'il est protégé ou non.
Le plugin accès restreint propose une solution, fonctionnelle mais techniquement pas très satisfaisante.
Ce serait à réécrire à base de htaccess pour que l'url d'un document ne change pas selon qu'il est protégé ou non.
Mais vu que maintenant on peut lier un même document à plusieurs choses (et pas que des articles/rubriques) différentes, comment le plugin décide-t-il si un document est restreint ou pas ?
Déjà il y a le cas où un même document est lié à un objet restreint et un autre public. => restreint ou pas ?
Et il y a le cas où un même document est lié à deux objets ayant des restrictions différents. => restreint mais avec quels droits ?
Et alors si on pose les mêmes questions avec plus de deux objets !...
Si le visiteur à le droit de voir un des objets auquel est rattaché le document, alors celui-ci lui est visible aussi.
C'est la règle de sécu la plus faible qui s'applique.
Le plugin accès restreint propose une solution, fonctionnelle mais
techniquement pas très satisfaisante.
Ce serait à réécrire à base de htaccess pour que l'url d'un document
ne change pas selon qu'il est protégé ou non.
Mais vu que maintenant on peut lier un même document à plusieurs
choses (et pas que des articles/rubriques) différentes, comment le
plugin décide-t-il si un document est restreint ou pas ?
Déjà il y a le cas où un même document est lié à un objet restreint et
un autre public. => restreint ou pas ?
Et il y a le cas où un même document est lié à deux objets ayant des
restrictions différents. => restreint mais avec quels droits ?
Et alors si on pose les mêmes questions avec plus de deux objets !...
Bonjour,
Disons que pour faire simple, le but se limiterait à protéger les
documents uploadés au départ depuis un article inclus dans l'espace
restreint ; je dirais que dans un tel cas ce qui est recherché étant la
restriction, l'enlever sans effacer le doc ne soit pas indispensable, et
que si vouloir le rendre public supposait un nouvel upload, ce ne serait
pas gênant ;
Donc même l'upload dans un répertoire distinct de IMG serait
concevable...si ça permettait d'éviter l'essentiel : laisser un accès
public des objets qu'on voudrait garder restreint.
Plutôt mettre un suffixe ou un sous-dossier différent aux documents
suivant leur état de protection au moment de l'upload ou du
changement d'état de protection, comme ça on a juste une seule règle
à écrire.
Plutôt mettre un suffixe ou un sous-dossier différent aux documents
suivant leur état de protection au moment de l'upload ou du
changement d'état de protection, comme ça on a juste une seule règle
à écrire.
bonsoir,
Ou : si ils sont uploadés depuis un espace restreint, ils sont renommés
avec un préfixe prévu pour les protéger dans un .htaccess générique à
/IMG prévu pour ; et si on les appelle depuis un objet non protégé, on
vérifie toujours leur attachement au parent protégé et si celui-ci n'est
plus protégé, on les renome en enlevant le préfixe avant de les envoyer.
Mais ça supposerait pour être propre, un mécanisme d'alerte sur les
fichiers associés si on lève la protection d'un espace restreint ou si
on déplace un article d'un espace restreint vers un espace public.
Plutôt mettre un suffixe ou un sous-dossier différent aux documents
suivant leur état de protection au moment de l'upload ou du
changement d'état de protection, comme ça on a juste une seule règle
à écrire.
Plutôt mettre un suffixe ou un sous-dossier différent aux documents
suivant leur état de protection au moment de l'upload ou du
changement d'état de protection, comme ça on a juste une seule règle
à écrire.
oui, entièrement d'accord. go go go
heu, pas sur de comprendre....
Si ca veut dire changer l'url des document quand on publie l'article, ca ne me parait pas etre une super idée.
Perso,quand j'ai besoin de protéger documents, j'utilise un squelette qui fait un premier tri histoire d'exploiter le cache pour les documents d'objets publiés:
- le document correspond à un objet publié => il est renvoyé sans autre verif.
- sinon
- si la personne n'est pas authentifiée, rien
- pour les utilisateurs authentifiés, ca utilise l'autorisation voir_document
le plus gros probleme technique, c'est que le header ne peut pas etre renvoyé avec #HEADER dans un squelette inclus.
Idéalement, pour les documents non protégés, il faudrait mettre directement le contenu du document en cache (quoi que, ca pose la question de la taille du cache, mais ca evite de faire systématiquement appel au wrapper qui bouffe de la RAM)
en un peu plus raffiné selon qu'on veut ou non protéger les documents des breves, rubriques...
Le but restant de limiter les traitements dans les cas généraux (document public et accès anonymes) et de s'appuyer sur la mecanique standard (autorisations / squelettes)
L'avantage c'est que du coup, on peut imaginer sortir le contenu d'IMG du htdoc.
Mais bon, perso, je l'utilise uniquement sur certains types de documents (et je place mon htaccess dans IMG).
RewriteCond %{REQUEST_URI} IMG/(.*)\.(doc|pdf|sxw|ppt|ps|txt|xls|html|DOC|PDF|SXW|PPT|PS|TXT|XLS|HTML)$
RewriteRule (.*) /spip.php?page=wrapper&file=%{REQUEST_URI}&link=$1
Plutôt mettre un suffixe ou un sous-dossier différent aux documents
suivant leur état de protection au moment de l'upload ou du
changement d'état de protection, comme ça on a juste une seule règle
à écrire.
oui, entièrement d'accord. go go go
heu, pas sur de comprendre....
Si ca veut dire changer l'url des document quand on publie l'article,
ca ne me parait pas etre une super idée.
Perso,quand j'ai besoin de protéger documents, j'utilise un squelette
qui fait un premier tri histoire d'exploiter le cache pour les
documents d'objets publiés:
- le document correspond à un objet publié => il est renvoyé sans
autre verif.
- sinon
- si la personne n'est pas authentifiée, rien
- pour les utilisateurs authentifiés, ca utilise l'autorisation
voir_document
le plus gros probleme technique, c'est que le header ne peut pas etre
renvoyé avec #HEADER dans un squelette inclus.
Idéalement, pour les documents non protégés, il faudrait mettre
directement le contenu du document en cache (quoi que, ca pose la
question de la taille du cache, mais ca evite de faire
systématiquement appel au wrapper qui bouffe de la RAM)
en un peu plus raffiné selon qu'on veut ou non protéger les documents
des breves, rubriques...
Le but restant de limiter les traitements dans les cas généraux
(document public et accès anonymes) et de s'appuyer sur la mecanique
standard (autorisations / squelettes)
L'avantage c'est que du coup, on peut imaginer sortir le contenu d'IMG
du htdoc.
Mais bon, perso, je l'utilise uniquement sur certains types de
documents (et je place mon htaccess dans IMG).
RewriteCond %{REQUEST_URI}
IMG/(.*)\.(doc|pdf|sxw|ppt|ps|txt|xls|html|DOC|PDF|SXW|PPT|PS|TXT|XLS|HTML)$
Celà renvoit quand-même au problème de l'accès ouvert par défaut aux
contenus d'IMG ; peut-être l'approche rationnelle serait comment
autoriser les accès aux documents propres aux usages standards de spip
tout en protégeant par défaut tout accès direct aux contenus d'IMG ?
Parce qu'en l'état httrack URL/IMG permet dans tous les cas de tout
récupérer, y compris ce qui est associé à du contenu non-publié.
C'est ce qui me faisait poser la question "à moyen terme" au départ.
Plutôt mettre un suffixe ou un sous-dossier différent aux documents
suivant leur état de protection au moment de l'upload ou du
changement d'état de protection, comme ça on a juste une seule règle
à écrire.
oui, entièrement d'accord. go go go
heu, pas sur de comprendre....
Si ca veut dire changer l'url des document quand on publie l'article,
ca ne me parait pas etre une super idée.
Perso,quand j'ai besoin de protéger documents, j'utilise un squelette
qui fait un premier tri histoire d'exploiter le cache pour les
documents d'objets publiés:
- le document correspond à un objet publié => il est renvoyé sans
autre verif.
- sinon
- si la personne n'est pas authentifiée, rien
- pour les utilisateurs authentifiés, ca utilise l'autorisation
voir_document
le plus gros probleme technique, c'est que le header ne peut pas etre
renvoyé avec #HEADER dans un squelette inclus.
Idéalement, pour les documents non protégés, il faudrait mettre
directement le contenu du document en cache (quoi que, ca pose la
question de la taille du cache, mais ca evite de faire
systématiquement appel au wrapper qui bouffe de la RAM)
en un peu plus raffiné selon qu'on veut ou non protéger les documents
des breves, rubriques...
Le but restant de limiter les traitements dans les cas généraux
(document public et accès anonymes) et de s'appuyer sur la mecanique
standard (autorisations / squelettes)
L'avantage c'est que du coup, on peut imaginer sortir le contenu d'IMG
du htdoc.
Mais bon, perso, je l'utilise uniquement sur certains types de
documents (et je place mon htaccess dans IMG).
RewriteCond %{REQUEST_URI}
IMG/(.*)\.(doc|pdf|sxw|ppt|ps|txt|xls|html|DOC|PDF|SXW|PPT|PS|TXT|XLS|HTML)$
Celà renvoit quand-même au problème de l'accès ouvert par défaut aux
contenus d'IMG ;
je disais que je posais un .htaccess dans IMG
Et j'ajoutais qu'on pouvait meme envisager de mettre le contenu hors du htdoc (tout en continuant à utiliser les liens vers /IMG/...)
peut-être l'approche rationnelle serait comment
autoriser les accès aux documents propres aux usages standards de spip
tout en protégeant par défaut tout accès direct aux contenus d'IMG ?
Parce qu'en l'état httrack URL/IMG permet dans tous les cas de tout
récupérer, y compris ce qui est associé à du contenu non-publié.
c'est vrai que par defaut, on pourrait au moins poser un index.html dans tous ces dossiers pour ceux qui ne peuvent pas jouer avec le .htaccess
Celà renvoit quand-même au problème de l'accès ouvert par défaut aux
contenus d'IMG ;
je disais que je posais un .htaccess dans IMG
Et j'ajoutais qu'on pouvait meme envisager de mettre le contenu hors
du htdoc (tout en continuant à utiliser les liens vers /IMG/...)
Oui, excuse-moi, c'est en quelque sorte comme si je t'avais paraphrasé.
Celà m'arrive souvent, malgré moi.
peut-être l'approche rationnelle serait comment
autoriser les accès aux documents propres aux usages standards de spip
tout en protégeant par défaut tout accès direct aux contenus d'IMG ?
Parce qu'en l'état httrack URL/IMG permet dans tous les cas de tout
récupérer, y compris ce qui est associé à du contenu non-publié.
c'est vrai que par defaut, on pourrait au moins poser un index.html
dans tous ces dossiers pour ceux qui ne peuvent pas jouer avec le
.htaccess
l'index.html n'empêcherait pas d'en faire un miroir avec un logiciel dédié.
Ou considérer que, _par défaut_, comme cela a toujours été considéré dans SPIP, un site Web n'est pas une banque, et que laisser l'accès libre aux images, comme on laisse l'accès aux squelettes, fait partie de la règle du jeu. On ne bloque, _par défaut_, que pour les dossiers contenant des éléments sensibles (config, tmp).
Ce qui n'interdit pas, par ailleurs, d'avoir des plugins qui permettent de bloquer certains accès pour les cas spécifiques.
Ou considérer que, _par défaut_, comme cela a toujours été considéré dans SPIP, un site Web n'est pas une banque, et que laisser l'accès libre aux images, comme on laisse l'accès aux squelettes, fait partie de la règle du jeu. On ne bloque, _par défaut_, que pour les dossiers contenant des éléments sensibles (config, tmp).
Ce qui n'interdit pas, par ailleurs, d'avoir des plugins qui permettent de bloquer certains accès pour les cas spécifiques.
A*
c'est vrai que par defaut, on pourrait au moins poser un index.html dans tous ces dossiers pour ceux qui ne peuvent pas jouer avec le .htaccess
Nul souci ici de "fermer" dans un état d'esprit "propriétaire", mais
plutôt celui de sécuriser par défaut, notamment pour avoir constaté de
visu et très récemment des hacks s'amusant avec /IMG.
Si spip "protège" ses articles non-publiés, protéger de même ses
documents "non-publiés" m'y semblerait logique, en marge de toute
présomption quant à l'usage particulier du logiciel. Pas à toi ?
Ou considérer que, _par défaut_, comme cela a toujours été considéré dans SPIP, un site Web n'est pas une banque, et que laisser l'accès libre aux images, comme on laisse l'accès aux squelettes, fait partie de la règle du jeu. On ne bloque, _par défaut_, que pour les dossiers contenant des éléments sensibles (config, tmp).
je ne parle pas de bloquer mais juste d'eviter au premier venu de lister les documents.
avoir des contenus rédactionnels inaccessibles mais les pieces jointes listables me parait un peu dommage.
C'est pas difficile d'ajouter un index vide à la création des sous-repertoires.
Ce qui n'interdit pas, par ailleurs, d'avoir des plugins qui permettent de bloquer certains accès pour les cas spécifiques.
oui ca on est bien d'accord que ca doit etre un plugin