Je viens de parcourir tout le guide (je finirai par le connaître par coeur) mais je n’ai pas trouvé (peut-être que ça m’a échappé, je suis allé un peu vite) comment « contextualiser » une boucle pour que, par exemple, me trouvant dans la page sommaire.html, j’affiche uniquement les articles de la rubrique n°1. J’ai bien essayé, un peu de toutes les manières possibles et imaginables, en partant sur la base d’un {id_rubrique=1} mais ça n’a pas du tout fonctionné.
J’ai fait un truc dans ce style :
Le code que tu indiques fonctionne parfaitement : es-tu certain d'avoir un
article **publié** (et pas à une date ultérieure) dans la rubrique n° 1 ?
Idem pour moi, ça fonctionne parfaitement. Il faut évidemment qu'il y ait un article _directement_ dans la rubrique 1 (et non dans une de ses sous-rubriques).
Il faut évidemment qu'il y ait un article _directement_ dans la rubrique 1
(et non dans une de ses sous-rubriques).
Pour prendre un article dans l'une quelconque des sous-rubriques de la
rubrique 1, utiliser {id_secteur=1} : cela fonctionnera à condition que la
rubrique 1 ne soit pas elle même une sous-rubrique : il faut qu'elle figure
directement "à la racine du site".
A quoi servent les fichiers data/.htpasswd et data/.htpasswd-admin ?
J'ai un pb car ces fichiers n'ont pas les droits 'w' (chez AMEN.fr, les
fichiers sont toujours créés avec les droits "644", et doivent être
manuellement passés à "666" via ftp). Comme ces fichiers sont invisibles
sous ftp, on ne peut pas en modifier les droits par la suite !!!
Je suggère donc que ces fichiers soient distribués sous les noms
data/passwd et data/passwd-admin (htpasswd et htpasswd-admin
deviennent aussi invisibles), avec demande à l'utilisateur de leur donner
les droits en écriture avant de les renommer tel qu'attendu.
Je me demande à quoi ils servent car après création d'un nouveau rédacteur,
création accompagnée d'une bordée d'injures MySQL concernant le non-accès en
écriture aux dits fichiers, la table spip-auteurs est correctement
renseignée et la connexion du nouvel utilisateur fonctionne correctement?...
@ François G-Hamonno (fhamonno@club-internet.fr) :
A quoi servent les fichiers data/.htpasswd et data/.htpasswd-admin ?
à rien sur la plupart des installations, mais ils peuvent être utilisés pour
sécuriser d'autres parties du site via les mots de passe spip. Par exemple,
si vous avez des stats gérées par un programme externe à spip, il est aisé
de les restreindre aux seuls rédacteurs (ou admins) de spip en utilisant le
fichier .htaccess (ou .htaccess-admin)
J'ai un pb car ces fichiers n'ont pas les droits 'w' (chez AMEN.fr, les
fichiers sont toujours créés avec les droits "644", et doivent être
manuellement passés à "666" via ftp). Comme ces fichiers sont invisibles
sous ftp, on ne peut pas en modifier les droits par la suite !!!
Il faut trouver un client ftp qui accepte de les afficher. Ou tenter de le
faire via une script php du genre
<?
chmod ('666', '.htpasswd');
?>
Je suggère donc que ces fichiers soient distribués sous les noms
data/passwd et data/passwd-admin (htpasswd et htpasswd-admin
deviennent aussi invisibles), avec demande à l'utilisateur de leur donner
les droits en écriture avant de les renommer tel qu'attendu.
Non, car on casserait les sites existants, et sur une fonctionnalité de
sécurité c'est pas franchement sympa.
Le 23:39 13/12/01 +0100, Fil nous a écrit :
****** Message d'origine ******
J'ai un pb car ces fichiers n'ont pas les droits 'w' (chez AMEN.fr, les
fichiers sont toujours créés avec les droits "644", et doivent être
manuellement passés à "666" via ftp). Comme ces fichiers sont invisibles
sous ftp, on ne peut pas en modifier les droits par la suite !!!
Il faut trouver un client ftp qui accepte de les afficher.
Ce n'est probablement pas un problème de client mais de paramétrage du
serveur, donc ...
Ou tenter de lec faire via une script php du genre
<?
chmod ('666', '.htpasswd');
?>
Possible... mais du coup contradictoire avec
Je suggère donc que ces fichiers soient distribués sous les noms
data/passwd et data/passwd-admin (htpasswd et htpasswd-admin
deviennent aussi invisibles), avec demande à l'utilisateur de leur donner
les droits en écriture avant de les renommer tel qu'attendu.
A la limite un autre nom que .htxxxx c'est plus prudent! Seul .htaccess
doit s'appeller comme ça. le fichier de mot de passe est définit dans ce
fichier et peut donc 1) être placé où on veut, 2) nommer comme on veut.
Non, car on casserait les sites existants, et sur une fonctionnalité de
sécurité c'est pas franchement sympa.
Oh Fil ;~}
Que le fichier s'appelle .truc ou .machin ou truc ou machin cela n'a rien à
voir avec la sécurité (à moins d'avoir une vision 'à la Bill' de la
sécurité et penser qu'il suffit de mettre l'attibut caché à un fichier pour
le protéger!). Ce sont les droits sur ce fichier qui comptent!
Et là, des droits 666 ;~{ (traduction: lisible/ecrivable par tout le monde!)
Que le fichier s'appelle .truc ou .machin ou truc ou machin cela n'a rien à
voir avec la sécurité (à moins d'avoir une vision 'à la Bill' de la
sécurité et penser qu'il suffit de mettre l'attibut caché à un fichier pour
le protéger!). Ce sont les droits sur ce fichier qui comptent!
Et là, des droits 666 ;~{ (traduction: lisible/ecrivable par tout le monde!)
On ne se comprend pas : sur le site X je protège le dossier Z via un
.htaccess paramétré pour demander un mot de passe et le valider dans le
fichier /chemin/vers/mon/spip/ecrire/data/.htpasswd-admin ; Je fais ensuite
la mise à jour de spip, et ce fichier .htpasswd-admin ne correspond plus aux
données de spip : crack!
Les droits en 666, c'est un autre type de problème, inhérent au travail sur
un serveur mutualisé et au modèle de sécurité (faible) d'une config standard
d'apache-php. En gros tous les utilisateurs du serveur web peuvent envoyer
des scripts php qui s'exécutent tous avec le même uid : c'est pas bien, mais
c'est hors de portée de spip.
>Il faut trouver un client ftp qui accepte de les afficher.
Ce n'est probablement pas un problème de client mais de paramétrage du
serveur, donc ...
Il faudra certainement faire un chmod automatique dans SPIP à 666.
Normalement SPIP règle le umask (droits d'accès par défaut des
fichiers créés) comme il faut, mais peut-être que ton hébergeur
a désactivé la fonction.
Oh Fil ;~}
Que le fichier s'appelle .truc ou .machin ou truc ou machin cela n'a
rien à
voir avec la sécurité (à moins d'avoir une vision 'à la Bill' de la
sécurité et penser qu'il suffit de mettre l'attibut caché à un fichier
pour
le protéger!). Ce sont les droits sur ce fichier qui comptent!
Et là, des droits 666 ;~{ (traduction: lisible/ecrivable par tout le
monde!)
De ce côté-là, il ne faut pas se faire d'illusions. Aucun programme
exécuté par un serveur Web, destiné à être compatible avec une
multitude d'environnements différents, et ayant besoin d'un accès
fichier, ne sera sécurisé vis-à-vis des autres utilisateurs Unix,
si ceux-ci ont un accès direct en Telnet ou SSH.
C'est à cause du principe d'exécution des CGI et assimilés sur un
serveur Web : ils sont exécutés sous l'identité du serveur Web,
non du propriétaire du compte qui les contient. Du coup, on est
obligé de prévoir le changement de droits des répertoires en 666
pour que le serveur puisse écrire dans des répertoires dont il
n'est pas propriétaire.
La chose importante, c'est de sécuriser SPIP vis-à-vis des accès
extérieurs (par le Web). D'où la présence d'un .htaccess disant
"deny from all" dans ecrire/data. Le problème est que sur les
serveurs ne reconnaissant pas .htaccess (IIS...), ça ne protège rien.
Ceci dit, pour l'instant SPIP n'a pas l'air de fonctionner sous IIS.
Mais la présence même de ces .htpasswd n'est pas forcément une bonne
idée (même si c'est pratique).
Ouh là les gars, z'êtes en train de causer sur la liste SPIP, là! Passez sur spip-dev si vous voulez causer technique, parce que là, vous pourriez tout aussi bien écrire en chinois que ça ferait le même effet.
ARNO*
At 10:41 +0100 14/12/01, Antoine Pitrou et les autres wrote:
Salut,
Il faudra certainement faire un chmod automatique dans SPIP à 666.
Normalement SPIP règle le umask (droits d'accès par défaut des
fichiers créés) comme il faut, mais peut-être que ton hébergeur
a désactivé la fonction.
le protéger!). Ce sont les droits sur ce fichier qui comptent!
> Et là, des droits 666 ;~{ (traduction: lisible/ecrivable par tout le
> monde!)
fichier, ne sera sécurisé vis-à-vis des autres utilisateurs Unix,
si ceux-ci ont un accès direct en Telnet ou SSH.
C'est à cause du principe d'exécution des CGI et assimilés sur un
serveur Web : ils sont exécutés sous l'identité du serveur Web,
non du propriétaire du compte qui les contient. Du coup, on est
obligé de prévoir le changement de droits des répertoires en 666
pour que le serveur puisse écrire dans des répertoires dont il
n'est pas propriétaire.
