Bonjour,
Il y a qqch que je n'ai pas vu dans le code,
ou bien est-ce que la création de fichier htpasswd
proposé dans le menu de configuration est une vétusté
aujourd'hui dépourvue d'opérationnalité ?
Emmanuel
Cela sert pour les gens qui veulent servir des accès SPIP pour contrôler
l'accès à une autre partie du site (non gérée par SPIP). Normalement, la
génération du fichier est dans inc_acces.php3.
Bref, cela sert toujours, quoique pour très peu de personnes.
a+
Antoine.
Le pb c'est que dans inc_cron, on remet systématiquement un
"deny from all" dans le .htacces, ce qui me parait contradictoire
avec le fait d'y mettre un htpasswd.
Emmanuel
Le pb c'est que dans inc_cron, on remet systématiquement un
"deny from all" dans le .htacces, ce qui me parait contradictoire
avec le fait d'y mettre un htpasswd.
C'est que "le .htaccess" n'existe pas ; il y a un .htaccess dans data/
ou CACHE/ ; qui est remis périodiquement par inc_cron, car ces
répertoires sont toujours en "deny for all" ; mais par ailleurs
d'autres .htaccess peuvent utiliser les .htpasswd créés par SPIP, par
exemple ecrire/.htaccess si on veut protéger ecrire/ avec cette (peu
recommandable) méthode.
-- Fil
Donc si j'ai bien compris, spip met dans data/ une version "AUTH_FILE"
de sa table SQL des auteurs, mais c'est aux utilisateurs de créer à la main
le htacces qui va dire qu'il faut l'utiliser ?
Si c'est ça deux remarques:
1. ce n'est pas dans les habitudes de Spip de faire les choses à moitié;
2. mettre un AUTH_FILE dans l'arborescence est déconseille par la doc Apache,
et on le comprend: le fichier créé l'étant en chmod 666, ça veut dire que n'importe
quelle personne ayant un compte sur le serveur peut faire du grabuge avec ça.
Personnellement, je pense qu'il vaudrait mieux retirer ce truc là.
Emmanuel
Déesse A. a écrit :
Le pb c'est que dans inc_cron, on remet systématiquement un
"deny from all" dans le .htacces, ce qui me parait contradictoire
avec le fait d'y mettre un htpasswd.C'est que "le .htaccess" n'existe pas ; il y a un .htaccess dans data/
ou CACHE/ ; qui est remis périodiquement par inc_cron, car ces
répertoires sont toujours en "deny for all" ; mais par ailleurs
d'autres .htaccess peuvent utiliser les .htpasswd créés par SPIP, par
exemple ecrire/.htaccess si on veut protéger ecrire/ avec cette (peu
recommandable) méthode.Donc si j'ai bien compris, spip met dans data/ une version "AUTH_FILE"
de sa table SQL des auteurs, mais c'est aux utilisateurs de créer à la main
le htacces qui va dire qu'il faut l'utiliser ?Si c'est ça deux remarques:
1. ce n'est pas dans les habitudes de Spip de faire les choses à moitié;
2. mettre un AUTH_FILE dans l'arborescence est déconseille par la doc Apache,
et on le comprend: le fichier créé l'étant en chmod 666, ça veut dire que n'importe
quelle personne ayant un compte sur le serveur peut faire du grabuge avec ça.Personnellement, je pense qu'il vaudrait mieux retirer ce truc là.
Emmanuel
le but des fichiers .htaccess dans CACHE et ecrire/data est d'empêcher l'internaute d'accéder à ces répertoires en saissant l'url, et non de sélectionner ceux qui peuvent les visiter.
Donc si j'ai bien compris, spip met dans data/ une version "AUTH_FILE"
de sa table SQL des auteurs, mais c'est aux utilisateurs de créer à la
main
le htacces qui va dire qu'il faut l'utiliser ?
Oui.
Si c'est ça deux remarques:
1. ce n'est pas dans les habitudes de Spip de faire les choses à moitié;
Normal, puisque le htaccess dépend des besoins de l'utilisateur, hors
SPIP.
2. mettre un AUTH_FILE dans l'arborescence est déconseille par la doc
Apache,
et on le comprend: le fichier créé l'étant en chmod 666, ça veut dire
que n'importe
quelle personne ayant un compte sur le serveur peut faire du grabuge
avec ça.
Tout juste, c'est pour ça qu'il faut l'activer à la main dans la config
de SPIP.
De toute façon le répertoire data est sensible, ainsi que
inc_connect.php3, il faut donc faire les chmod adéquats s'il y a un
risque du côté des personnes ayant des comptes Unix.
Le mieux serait de reprendre la logique du nouveau spip_loader pour
détecter les droits Unix au plus juste au lieu de faire des chmod 666 à
tout va.
a+
Perso, j'utilise le ".htpasswd" généré par spip et c'est très bien comme ca.
Dans le cadre d'un intranet, c'est une solution satisfaisante.
C'est de toutes facons la pratique courante sous apache : d'un coté les
comptes, de l'autre les droits d'accès par repertoire.
Ca manque peut etre d'un petit exemple dans le .htaccess de /CACHE (en
commentaire : si vous activez la generation et que vous mettez ca, les
admins auront accès au repertoire, si vous mettez ca, les redacteurs aussi
...).
Mais bon, le genre de bidouille qui peut bloquer un site, c'est peut etre
plus prudent de ne pas les rendre trop facilement accessibles, que personne
ne le fasse "par accident".