[Spip] acces restreint + IMG = problème
martin
je ne me suis aperçu que récemment que les documents publiés dans les rubriques à accès restreint étaient quand même indexés par Google. Ça m'a valu d'avoir un peu chaud aux fesses.
J'ai ensuite découvert que les versions récentes du plugin permettaient de masquer les documents joints. Mais depuis que j'ai activé cette option, ce sont TOUS les documents dans IMG qui posent problème !
Avez-vous une idée de piste pour résoudre ce problème ?
le site : www.zazipo.net
--
Martin Granger
_______________________________________________
liste spip
sp...@rezo.net - désabonnement : envoyer un mail à spip...@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
http://archives.rezo.net/spip.mbox/
Documentation de SPIP : http://www.spip.net/
Irc : de l'aide à toute heure : http://spip.net/irc
Ysabeau
> Bonjour,
> je ne me suis aperçu que récemment que les documents publiés dans les rubriques à accès restreint étaient quand même indexés par Google. Ça m'a valu d'avoir un peu chaud aux fesses.
> J'ai ensuite découvert que les versions récentes du plugin permettaient de masquer les documents joints. Mais depuis que j'ai activé cette option, ce sont TOUS les documents dans IMG qui posent problème !
> Avez-vous une idée de piste pour résoudre ce problème ?
>
> le site : www.zazipo.net
Configurer le fichier robot.txt pour lui interdire l'accès du dossier img ?
http://fr.wikipedia.org/wiki/Robots.txt
--
Ysabeau
Suske
> J'ai ensuite découvert que les
> versions récentes du plugin permettaient de masquer les documents joints.
> Mais depuis que j'ai activé cette option, ce sont TOUS les documents dans
> IMG qui posent problème ! Avez-vous une idée de piste pour résoudre ce
> problème ?
Quel est le problème ? Le contrôle des documents passe par un script
(acceder_documents ?) qui est lancé systématiquement lors de requêtes vers
IMG, c'est forcé (c'est un .htaccess qui gère ça je crois).
Si google a pu lister vos documents c'est que l'affichage de l'index des
dossiers est autorisé: il y a moyen d'interdire ça sur le serveur (c'est le
mieux) ou avec une ligne dans un .htaccess dans IMG par ex.
Options -Indexes
Cela n'empêche pas l'accès aux documents mais bien qu'ils soitn tous listés
en parcourantla racine des répertoire...
--
Suske
~e
J'utilise aussi ce plugin accès restreint sur un SPIP 2.1.10.
Après lecture d'une pléthore d'information à ce sujet, j'ai cru comprendre que beaucoup rencontrent un trou de sécurité très gênant qui permet à quiconque d'accéder au document à partir de son URL complète.
C'est-à-dire qu'un utilisateur non authentifié peut accéder au document s'il possède son URL complète.
L'idée de placer un Option -Indexes dans le .htaccess est bonne, puisqu'elle empêche le référencement par Google. Mais elle ne solutionne le problème que partiellement. En effet, au moindre oubli, c'est la sécurité de tous vos fichiers liés à une rubrique ou article en accès restreint qui est compromise.
Le problème vient du fichier action/acceder_document.php intégré à ce plugin. En effet, d'un point de vu restriction d'accès, la seule vérification qui est faite pour l'accès aux fichiers est verifier_cle_action("$id_du_document,$nom_du_fichier", $cle);
Cette fonction renvoie en fait à la vérification d'égalité entre la clef de hachage sha1 de l'identifiant de fichier concaténé à son nom, avec cette fameuse $cle (présente dans l'url) ;
Pour être clair cela ne permet en aucun cas de savoir si l'utilisateur connecté a un droit d'accès audit fichier.
N'ayant pas trouvé de solution sur le net, j'ai tenté de résoudre ce pb (de manière assez élégante je crois) en ajoutant une fonction nommée verifier_droit_acces_document($doc)
Cette fonction permet d'interroger la base de donnée en vérifiant que l'utilisateur connecté $GLOBALS[auteur_session][id_auteur] a bien un droit d'accès au fichier en question $doc[id_document]
Mes fonctions gèrent les cas de documents liés à un article, à une rubrique ainsi qu'au forum (que j'utilise d'ailleurs pour gérer les petites annonces).
Au cas où le fichier n'est pas dans une zone d'accès restreint, j'appelle une autre fonction verifie_document_non_restreint($id_document) qui bien sûr outrepasse cette vérification d'accès si le doc en question est laissé en libre accès pour tous.
Je n'ai pas le petit addon de ce plugin (d'ailleurs très bien fait) sur mon pc, c'est à mon taf, mais s'il intéresse qqn je le partagerai bien sûr. !
--
e.r
martin
> Quel est le problème ? Le contrôle des documents passe par un script
> (acceder_documents ?) qui est lancé systématiquement lors de requêtes vers
> IMG, c'est forcé (c'est un .htaccess qui gère ça je crois).
Ben justement, le problème c'est que l'accès aux documents est interdit *même* s'ils sont joints à des articles non protégés. Je pense que c'est anormal, ou du moins illogique.
> Si google a pu lister vos documents c'est que l'affichage de l'index des
> dossiers est autorisé: il y a moyen d'interdire ça sur le serveur (c'est le
> mieux) ou avec une ligne dans un .htaccess dans IMG par ex.
>
> Options -Indexes
Du coup j'ai une question : est-ce que mettre un index.html vide à la racine de IMG me protègerait de la même façon ?
martin
> Je n'ai pas le petit addon de ce plugin (d'ailleurs très bien fait) sur mon pc, c'est à mon taf, mais s'il intéresse qqn je le partagerai bien sûr. !
Je pourrais être intéressé… à condition que sa mise en œuvre ne demande pas trop de compétences en php !
--
Martin Granger
Suske
> Le problème vient du fichier action/acceder_document.php intégré à ce
> plugin. En effet, d'un point de vu restriction d'accès, la seule
> vérification qui est faite pour l'accès aux fichiers est
> verifier_cle_action("$id_du_document,$nom_du_fichier",
> $cle);
> Cette fonction renvoie en fait à la vérification d'égalité entre la clef
> de hachage sha1 de l'identifiant de fichier concaténé à son nom, avec
> cette fameuse $cle (présente dans l'url) ;
> Pour être clair cela ne permet en aucun cas de savoir si l'utilisateur
> connecté a un droit d'accès audit fichier.
Ah bé oui en effet... :-/ Bon c'est pas gravissime dans l'usage que j'en ai
mais en effet, l'url "hashée" est donc accessible à tous.
> N'ayant pas trouvé de solution sur le net, j'ai tenté de résoudre ce pb
> (de manière assez élégante je crois) en ajoutant une fonction nommée
> verifier_droit_acces_document($doc)
>
> Cette fonction permet d'interroger la base de donnée en vérifiant que
> l'utilisateur connecté $GLOBALS[auteur_session][id_auteur] a bien un droit
> d'accès au fichier en question $doc[id_document]
>
> Mes fonctions gèrent les cas de documents liés à un article, à une
> rubrique ainsi qu'au forum (que j'utilise d'ailleurs pour gérer les
> petites annonces).
> Au cas où le fichier n'est pas dans une zone d'accès restreint, j'appelle
> une autre fonction verifie_document_non_restreint($id_document) qui bien
> sûr outrepasse cette vérification d'accès si le doc en question est laissé
> en libre accès pour tous.
>
> Je n'ai pas le petit addon de ce plugin (d'ailleurs très bien fait) sur
> mon pc, c'est à mon taf, mais s'il intéresse qqn je le partagerai bien
> sûr. !
Ah bé c'est sûr. Avec une petite config pour l'activer elle aurait bien sa
place dans le plugin sur la zone.
Suske
> Ben justement, le problème c'est que l'accès aux documents est interdit
> *même* s'ils sont joints à des articles non protégés. Je pense que c'est
> anormal, ou du moins illogique.
En fait, il n'est pas interdit mais les docs ne sont accessibles que via une
url "non devinable" et plus par leur url/nom de fichier. Je *croyais* que
cette fonction acceder_document était aussi l'occasion de tester les droits
du visiteurs sur la zone dans laquelle est publiée le document mais ce n'est
visiblement pas le cas (voir fonction de ~e).
>> Si google a pu lister vos documents c'est que l'affichage de l'index des
>> dossiers est autorisé: il y a moyen d'interdire ça sur le serveur (c'est
>> le mieux) ou avec une ligne dans un .htaccess dans IMG par ex.
>>
>> Options -Indexes
>
> Du coup j'ai une question : est-ce que mettre un index.html vide à la
> racine de IMG me protègerait de la même façon ?
Plus ou moins... Cela retournera très probablement le index.html (selon la
config du serveur). Mais pas seulement à la racine de IMG, à la racine de
tous les sous-dossiers également.
Option -Indexes renverra une erreur 403 (plus "propre").
--
Suske
martin
> Option -Indexes renverra une erreur 403 (plus "propre").
ok merci je vais m'orienter par là…
--
Martin Granger
martin
> Le 6 oct. 2011 à 08:27, Suske a écrit :
>> Option -Indexes renverra une erreur 403 (plus "propre").
Je reviens vers vous avec mes questions sur Accès restreint :
Si vous regardez ici
http://zazipo.net/Pirouesie-2009-photos-d-Elisabeth
vous constaterez que seules les miniatures sont visibles, l'image ne s'affiche pas en grand…
L'option "interdire la lecture" est cochée dans ecrire/?exec=acces_restreint_config
mais l'article en question est publié et n'est pas dans une zone restreinte.
Je pense que c'est le script acceder_document qui déconne, non ?
Personne n'a le même souci que moi ?
Denis Chenu
> Le 6 oct. 2011 à 14:19, martin a écrit :
>
>> Le 6 oct. 2011 à 08:27, Suske a écrit :
>>> Option -Indexes renverra une erreur 403 (plus "propre").
>
> Je reviens vers vous avec mes questions sur Accès restreint :
> Si vous regardez ici
> http://zazipo.net/Pirouesie-2009-photos-d-Elisabeth
> vous constaterez que seules les miniatures sont visibles, l'image ne s'affiche pas en grand…
> L'option "interdire la lecture" est cochée dans ecrire/?exec=acces_restreint_config
> mais l'article en question est publié et n'est pas dans une zone restreinte.
> Je pense que c'est le script acceder_document qui déconne, non ?
> Personne n'a le même souci que moi ?
>
>
doute un autre truc que le php qui donne une image.
http://zazipo.net/spip.php?action=acceder_document&arg=570&cle=65b30089511bf0abdbd955062deb23db939a7cf3&file=jpg%2FPirou_2009_032.jpg
JLuc
> Le 29/11/2011 15:02, martin a écrit :
>> Le 6 oct. 2011 à 14:19, martin a écrit :
>>
>>> Le 6 oct. 2011 à 08:27, Suske a écrit :
>>>> Option -Indexes renverra une erreur 403 (plus "propre").
>>
>> Je reviens vers vous avec mes questions sur Accès restreint :
>> Si vous regardez ici
>> http://zazipo.net/Pirouesie-2009-photos-d-Elisabeth
>> vous constaterez que seules les miniatures sont visibles, l'image ne s'affiche pas en grand…
>> L'option "interdire la lecture" est cochée dans ecrire/?exec=acces_restreint_config
>> mais l'article en question est publié et n'est pas dans une zone restreinte.
>> Je pense que c'est le script acceder_document qui déconne, non ?
>> Personne n'a le même souci que moi ?
>>
>>
> Chez moi ça marche en dehors de la mediabox. La mediabox attend sans
> doute un autre truc que le php qui donne une image.
> http://zazipo.net/spip.php?action=acceder_document&arg=570&cle=65b30089511bf0abdbd955062deb23db939a7cf3&file=jpg%2FPirou_2009_032.jpg
Tu utilises la thickbox.
Utilises la mediabox à la place :
les fonctions sont équivalentes, mais c'est ce qui est retenu pour l'avenir de SPIP.
JLuc
martin
> Tu utilises la thickbox.
> Utilises la mediabox à la place :
> les fonctions sont équivalentes, mais c'est ce qui est retenu pour l'avenir de SPIP.
SUPER ! Merci, ce simple conseil a résolu tous mes problèmes.
En fait j'avais bien vu que thickbox était obsolète, mais je le gardais parce qu'il a une fonction sympa : on peut cliquer sur une image pour passer à la suivante. Ça doit être possible de bricoler ça avec mediabox, mais ça n'a pas l'air de se faire par défaut. Je regarderai quand j'aurai le temps.
merci encore
--
Martin Granger
martin
Sur la page http://zazipo.net/Lecture-de-l-OuLiPo-le-10-octobre
Il y a des sons, (avec le plugin lecteur multimedia) mais ceux-ci sont inaccessibles.
Ils se trouvent dans le dossier /IMG/mp3 mais quand on essaie de les afficher via le navigateur on a le message suivant :
You don't have permission to access [le fichier] on this server
exemple :
http://zazipo.net/IMG/mp3/15bisforte_potje.mp3
Dans l'espace privé, sur la page http://zazipo.net/ecrire/?exec=acces_restreint_config
j'ai coché l'option "interdire la lecture" des documents joints si le texte auquel ils se rattachent n'est pas publié.
Mais les documents sont illisibles même si le texte est publié, alors je ne comprends plus rien !
phi...@gmail.com
J'ai ce problème également, et je suis très intéresse par la correction apportée par ~e.
Sa solution me paraît la bonne.
Comment l'obtenir ?
Merci,
PhJ
~e
Et bien comme j'expliquais à Nicolas, le principe d'installation de cette modif est simple.
Tu remplaces le fichier _repertoire_spip/plugins/acces_restreint_3_0/action/acceder_document.php par le fichier en pièce-jointe de ce mail. Et... c'est tout (j'ai intégré la fonction dump_array cette fois) !
Cette petite modif permet de filtrer l'accès aux documents sur un SPIP utilisant le plugin "accès restreint".
Pour visualiser les logs à des fins de debuggage (ou de contrôle), un fichier dans _repertoire_spip/tmp/acces_document.log est créé.
Le script est efficace, surtout en Intranet et sur un hébergement d'entreprise car probablement un peu coûteux en requête SQL.
Il est opérationnel pour un spip-2.1.10 et un spip-2.1.11, probablement le 2.1.12 bien que je n'ai pas eu l'occasion de tester.
et comme Nicolas le disait dans un précédent message, si tu mets en commentaire le "exit" de la ligne 56, ça te redirigera vers la page de login (bien que je ne l'aurai pas fait de cette façon).
Cordialement,
PS : ci-dessous un c/c de qq détails postés précédemment dans cette liste de diffusion
---------------------------------------------------------------------------------------
Pour plus de détail, voici ce que j'ai déjà écrit à ce sujet à la date du 05/10/2011 :
J'utilise aussi ce plugin accès restreint sur un SPIP 2.1.10.
Après lecture d'une pléthore d'information à ce sujet, j'ai cru comprendre que beaucoup rencontrent un trou de sécurité très gênant qui permet à quiconque d'accéder au document à partir de son URL complète.
C'est-à-dire qu'un utilisateur non authentifié peut accéder au document s'il possède son URL complète.
L'idée de placer un Option -Indexes dans le .htaccess est bonne, puisqu'elle empêche le référencement par Google. Mais elle ne solutionne le problème que partiellement. En effet, au moindre oubli, c'est la sécurité de tous vos fichiers liés à une rubrique ou article en accès restreint qui est compromise.
Le problème vient du fichier action/acceder_document.php intégré à ce plugin. En effet, d'un point de vu restriction d'accès, la seule vérification qui est faite pour l'accès aux fichiers est verifier_cle_action("$id_du_document,$nom_du_fichier", $cle);
Cette fonction renvoie en fait à la vérification d'égalité entre la clef de hachage sha1 de l'identifiant de fichier concaténé à son nom, avec cette fameuse $cle (présente dans l'url) ;
Pour être clair cela ne permet en aucun cas de savoir si l'utilisateur connecté a un droit d'accès audit fichier.
Cette fonction permet d'interroger la base de donnée en vérifiant que l'utilisateur connecté $GLOBALS[auteur_session][id_auteur] a bien un droit d'accès au fichier en question $doc[id_document]
Au cas où le fichier n'est pas dans une zone d'accès restreint, j'appelle une autre fonction verifie_document_non_restreint($id_document) qui bien sûr outrepasse cette vérification d'accès si le doc en question est laissé en libre accès pour tous.
e.r
Fil
un trou de sécurité très gênant qui permet à quiconque d'accéder au document à partir de son URL complète.
C'est-à-dire qu'un utilisateur non authentifié peut accéder au document s'il possède son URL complète.