[spip-dev] Re: [Spip] site sous spip + idee originale admin

63438612493668b99328 · Juin 6, 2002, 3:45

Comment ça 'si on passe' ???

Ben, il faut le travailler ton machin Rien que si on veut s'en servir pour
l'espace public, il faut se débarasser de la connexion obligatoire à la base
de données, déjà (avec des fichiers de session, par exemple).

J'aime bien l'idée actuelle de ne pas avoir DU TOUT a penser aux
boutons admin quand tu fais ton squelette. Comme en plus tu peux
désactiver les boutons "automatiques", ça me paraît bien de conserver
le fait qu'ils y soient par défaut (mais plus beaux).

Moi aussi, sauf que le "plus beaux" me paraît un peu superflu....
Et que le système du -dist est un pis-aller, et qu'il vaut mieux
s'en servir le moins possible (sans compter que ça complique).

a+

Antoine.

Nicolas_Hoizey2 · Juin 6, 2002, 3:47

Moi aussi, sauf que le "plus beaux" me paraît un peu superflu....

Ouais, bon, OK ...

Et que le système du -dist est un pis-aller, et qu'il vaut mieux
s'en servir le moins possible (sans compter que ça complique).

Tu parles en général, là, ou juste sur ce cas là ???

Sans les '-dist' des squelettes par défaut, impossible de mettre à
jour avec un simple "cvs co" sans tout écraser, c'est donc
indispensable, au moins pour mes nombreux sites ...

-Nicolas

fil · Juin 6, 2002, 3:49

@ Antoine Pitrou <antoine@rezo.net> :

> Comment ça 'si on passe' ???

Ben, il faut le travailler ton machin Rien que si on veut s'en servir pour
l'espace public, il faut se débarasser de la connexion obligatoire à la base
de données, déjà (avec des fichiers de session, par exemple).

Tu n'as de connexion obligatoire qu'en cas de la présence d'un cookie, ce
qui limite les dégâts. Mais j'ai lancé un appel pour que Nicolas et toi
fassiez au moins l'algo de création/vérification du numéro de session. Les
deux fonctions sont clairement étiquetées dans inc_sessions.php3, mais pour
l'instant j'ai mis un truc tout bête (et probablement pas sécure).

Moi aussi, sauf que le "plus beaux" me paraît un peu superflu....
Et que le système du -dist est un pis-aller, et qu'il vaut mieux
s'en servir le moins possible (sans compter que ça complique).

Une idée : on externalise cette fonction dans un fichier, et on laisse celui
qui veut en proposer un "plus beau", qu'on adopte. Laissons tomber les -dist.

-- Fil

Nicolas_Hoizey2 · Juin 6, 2002, 3:51

j'ai lancé un appel pour que Nicolas et toi fassiez au moins l'algo
de création/vérification du numéro de session.

Oui, oui, j'essaie de regarder ça demain !!!

Là je discute en SOAP, donc pas trop le temps ...

-Nicolas

63438612493668b99328 · Juin 6, 2002, 4:01

Nicolas :

Tu parles en général, là, ou juste sur ce cas là ???

En général... C'est largement mieux d'avoir une interface de config,
plutôt que des manips de fichier.

Fil :

Tu n'as de connexion obligatoire qu'en cas de la présence d'un cookie,
ce qui limite les dégâts. Mais j'ai lancé un appel pour que Nicolas et
toi fassiez au moins l'algo de création/vérification du numéro de
session. Les deux fonctions sont clairement étiquetées dans
inc_sessions.php3, mais pour l'instant j'ai mis un truc tout bête (et
probablement pas sécure).

A mon avis il faudra réécrire un bout, ne serait-ce que pour rajouter
le MD5 côté client en Jajascript.

fil · Juin 6, 2002, 4:08

A mon avis il faudra réécrire un bout, ne serait-ce que pour rajouter
le MD5 côté client en Jajascript.

Et les "secrets" du site et de l'auteur, changeants en fonction e la météo.

Si on l'utilise dans l'espace public (pour autre chose que les boutons
d'admin, qui peuvent conserver le cookie non-sécurisé) :

Dans le code commité, il y a deux types de visiteurs : $visiteur_authentifie
et $visiteur (pas authentifié). L'un ou l'autre des cookies déclenchent les
boutons d'admin.

Pour la vérif de session sans connexion à la base (et sans PHP4), il
faut a priori passer par des fichiers dans ecrire/data :
- soit un fichier unique contenant toutes les sessions
- soit un fichier par session
- soit un mix (disons 16 fichiers, en hashant par le contenu du cookie
(qui sera un md5 quelconque))

Dans le fichier de sessions, il faut penser à mettre *toutes* les données
relatives aux auteurs ayant des sessions en cours, de manière à pouvoir
reconstruire les enregistrements $auteur->xxxx

Le problème, c'est que ça rajoute du temps de traitement. Faudra
tester pour évaluer ça.

Peut-être une succession de lignes de php dans un fichier à includer :

<?php
function charge_auteur($session)

switch $session
case '123AB567BD': $auteur->id_auteur = 7; $auteur->nom='tutu'; ....
case '8988678765': ...

etc ? Ca devrait aller vite, d'includer un fichier temporaire ? Et tu peux
utiliser la "dernière connexion" de la base pour savoir lesquels mettre dans
le fichier.

-- Fil

63438612493668b99328 · Juin 6, 2002, 4:35

A mon avis il faudra réécrire un bout, ne serait-ce que pour rajouter
le MD5 côté client en Jajascript.

Et les "secrets" du site et de l'auteur, changeants en fonction e la
météo.

Oui.

Dans le fichier de sessions, il faut penser à mettre *toutes* les
données relatives aux auteurs ayant des sessions en cours, de manière à
pouvoir reconstruire les enregistrements $auteur->xxxx

Eventuellement (je verrais plutôt les infos principales), et surtout
pas le pass

Bon ça commence à se préciser, à mon avis :
- un cookie id_auteur (tout bête)
- un cookie session (md5 de choses et trucs)

Le nom du fichier session : md5(cookie session . alea site)
Comme ça même si qqn a accès à la liste des fichiers sessions,
il est bien avancé.
D'autre part tant qu'on n'a pas besoin des autres infos ($auteur->*),
pas besoin d'aller ouvrir le fichier session, suffit de vérifier
qu'il existe.

La seule chose qui me fait chier c'est que le cookie id_auteur
circule en clair.

a+

Antoine.

Thomas_NOEL · Juin 6, 2002, 4:46

Ah non ! Moi pas d'accord ! Là où je suis, il fait toujours beau.

Nicolas_Hoizey2 · Juin 6, 2002, 5:06

Hello,

je vois que vous êtes en train de griller pas mal de neurones sur ce
problème d'auth, alors que j'avais prévu d'en griller moi-même
plusieurs demain, donc je réagis en vitesse ...

Il me semble que tant qu'à gérer des accès côté public, autant le
faire à fond, c'est à dire avec la possibilité de mettre des
restrictions en lecture par rubrique, en cascade comme pour les
administrateurs locaux côté privé.

C'est certe plus compliqué, mais cela devrait couvrir tous les
besoins.

Nous sommes en train de travailler sur ce mécanisme, et je vous
explique comment nous faisons ci-après. Nous sommes conscients qu'une
gestion intégrée à SPIP serait bien meilleure, mais nous faisons ça
pour conserver la compatibilité avec les futures versions.

Voilà :

- une catégorie de mots clefs nommée 'auth' contient des noms de
groupes, par exemple : 'visiteur', 'commercial', 'admin', ...

- toute rubrique peut se voir affecter 0 à n groupes indiquant alors
une restriction de visibilité aux membres de ces groupes de la
rubrique et de ses sous-rubriques

- tout utilisateur peut faire partie de 0 à n groupes, ces
répartitions de groupes étant gérées pour l'instant hors de SPIP

- des fonctions dans 'mes_fonctions.php3' permettent de gérer les
 autorisation d'affichage. Dans une liste d'articles du sommaire, on
 va faire, par exemple :
 <BOUCLE_derniers_articles(ARTICLES){...}>
 <?php
 if ([(#ID_ARTICLE|auth_link_article)]) {
 ?>
 
 <a href="#URL_ARTICLE">#TITRE</a> 
 #DESCRIPTIF
 
 <?php
 }
 ?>
 </BOUCLE_derniers_articles>

    auth_link_article() renvoi true ou false suivant que l'utilisateur
    courant (cf session) a le droit ou non de voir l'article en
    question. Cette fonction accède (malheureusement) à la base de
    données pour récupérer la hiérarchie à vérifier, donc une mise en
    cache des hierarchies, avec infos de groupes, serait top

    Il faut de même une fonction auth_show_article() à mettre dans les
    squelettes d'article, et idem pour les autres éléments, rubriques,
    brèves, sites ...

L'inconvénient principal que je vois à ce système est qu'on est obligé
de vérifier les contenus à afficher à chaque fois, et que donc on perd
l'intérêt du cache dont les délais doivent être systématiquement à 0.

L'avantage par contre est que l'on peut ainsi pas mal personnaliser
les contenus en fonction des groupes de visiteurs.

Nous sommes en cours de conception et réalisation, donc toute bonne
idée sera la bienvenue ...

-Nicolas

fil · Juin 6, 2002, 6:22

> Dans le fichier de sessions, il faut penser à mettre *toutes* les
> données relatives aux auteurs ayant des sessions en cours, de manière à
> pouvoir reconstruire les enregistrements $auteur->xxxx

Eventuellement (je verrais plutôt les infos principales), et surtout
pas le pass

Avec mon système (celui qui est dans le cvs) on récupère tout l'objet auteur
sauf les mots de passe ni les liens auteurs<->articles.

Bon ça commence à se préciser, à mon avis :
- un cookie id_auteur (tout bête)

j'ai mis id_auteur@login, ce qui permet à la page 'login.php3' de préentrer
le login quand ce cookie-là est vivant. Il s'appelle spip_admin
(compatibilite cookie d'admin précédent).

- un cookie session (md5 de choses et trucs)

C'est ça. Il s'appelle spip_session

Le nom du fichier session : md5(cookie session . alea site)
Comme ça même si qqn a accès à la liste des fichiers sessions,
il est bien avancé.

Je croyais qu'il fallait un secret auteur ?? Du genre "déloguer" => change de
secret. Mais j'ai oublié toute cette discussion sur la sécurité, savoir ce
qu'on peut te piquer si on te pique ton coookie, etc.

D'autre part tant qu'on n'a pas besoin des autres infos ($auteur->*),
pas besoin d'aller ouvrir le fichier session, suffit de vérifier
qu'il existe.
La seule chose qui me fait chier c'est que le cookie id_auteur
circule en clair.

Qu'il soit possible de le voler est une chose (à mon avis pas gênante),
qu'il soit possible de le générer soi même pour obtenir un accès (même
minime) est plus gênant : il suffit d'avoir un secret lié à l'id_auteur et
de mettre dans le cookie id_auteur@login@secret ?

-- Fil

Administrator1 · Juin 6, 2002, 6:43

Hum…

J’avais patché la version précédante et j’avais procédé comme suis:

Ajouté un champ “auth” à spip_articles. Il pouvait prendre la valeur, 0 (défault), 1, 2, 3
Ajouté à spip_auteurs les “statut” suivant: 4membres 5comite 7bureau
Ajouté un auth.php3 qui permet le login, ecris les cookies, et contient une fonction de comparaison avec pour la correspondance statut (de spip_auteur) et auth (spip_article).

Et ça marche nikel. Mais comme j’ai migré vers une autre version, j’ai eut l’idée d’un filtre qui fasse tout ça, car comme ça: + simple pour les updates

Cordialement, Emilien

fil · Juin 6, 2002, 10:39

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

Il me semble que tant qu'à gérer des accès côté public, autant le
faire à fond, c'est à dire avec la possibilité de mettre des
restrictions en lecture par rubrique, en cascade comme pour les
administrateurs locaux côté privé.

Les admins restreints c'est une très mauvaise solution, pitié !

C'est certe plus compliqué, mais cela devrait couvrir tous les
besoins.

C'est pas vraiment la philosophie spip...

- une catégorie de mots clefs nommée 'auth' contient des noms de
groupes, par exemple : 'visiteur', 'commercial', 'admin', ...

Ca ne marche que parce que tu veux restreindre par mots-clés : moi je veux
restreindre par {age_redac}, par exemple...

- tout utilisateur peut faire partie de 0 à n groupes, ces
répartitions de groupes étant gérées pour l'instant hors de SPIP

Donc : attribuer les mots-clés sur des auteurs...

if ([(#ID_ARTICLE|auth_link_article)]) {

eurk !!

L'inconvénient principal que je vois à ce système est qu'on est obligé
de vérifier les contenus à afficher à chaque fois, et que donc on perd
l'intérêt du cache dont les délais doivent être systématiquement à 0.

Pas bon du tout.

Amha c'est pas la bonne direction : je crois qu'il faut augmenter un peu le
nombre de statuts possibles pour les auteurs (0 = admin [validation], 1 =
redacteur [acces a ecrire], 2 = visiteur [acces authentifie dans l'espace
public seulement]) et faire avec.

La protection se ferait avec une simple interdiction pour ceux dont le
statut n'est pas suffisant : restriction='authentifie,0,1' indique que si
($visiteur_authentifie AND $visiteur_authentifie->statut = 0 ou
$visiteur_authentifie->statut = 1) ça passe. Tout reste dans le cache.

Donc il faut un tag <ACCES restriction='authentifie,0,1'> ou un critère
{restriction=authentifie,0,1}, qui se code dans le cache sous la forme d'une
ligne php tout bête :
<?php if ($visiteur_authentifie AND ($visiteur_authentifie->statut == 0 OR
$visiteur_authentifie->statut == 1)) { ?>

(voire même, si on veut unifier, $visiteur->authentifie = true... je devrais
changer le modèle dans inc-public en conséquence).

Clairement, ce tag ne pourra pas fonctionner dans un contexte php : faire
juste attention à fermer juste avant et réouvrir juste après. Le tag fermant
</ACCES> se traduit juste par <? } ?> et je suggère qu'on n'ait pas de
'else' (sinon il faut donner des noms à ce qui deviendra des "boucles
d'accès", bonjour l'embrouille...)

Ensuite, pour faire une cuisine plus épicée, pas d'autre solution qu'un
recours à du code php (simple, mais du code quand même). Heureusement la
liste est là en support, et des exemples dans la doc...

-- Fil

63438612493668b99328 · Juin 6, 2002, 11:05

Fil wrote:

Avec mon système (celui qui est dans le cvs) on récupère tout l'objet auteur
sauf les mots de passe ni les liens auteurs<->articles.

Je sais mais toute la discussion était de le faire sans accès à la base et
avec le minimum de traitements

Je croyais qu'il fallait un secret auteur ?? Du genre "déloguer" => change de
secret. Mais j'ai oublié toute cette discussion sur la sécurité, savoir ce
qu'on peut te piquer si on te pique ton coookie, etc.

Ben, c'est pas indispensable. Disons que le secret site dure 24 ou 48h (je ne
sais plus) ; c'est le lire_meta('alea_ephemere'). Avec un secret auteur, ce
serait "peut-être un peu plus sûr". Le problème, c'est que si le secret site
est dans les métas (donc accessible immédiatement), pour le secret auteur
je ne vois au contraire pas trop comment faire sans la base.

Ceci dit pour l'unique problème du rejeu après déconnexion, il suffit d'effacer
toute trace de la session. Comme on choisit un cookie session différent la fois
suivante, l'ancien est totalement inutile. (je fais peut-être une erreur, là,
mais il est tard ;-))

Enfin bon, rassurons-nous : jusqu'à récemment, phpnuke stockait les mots
de passe en clair (dans la base, et peut-être même dans le cookie !).

La seule chose qui me fait chier c'est que le cookie id_auteur
circule en clair.

Qu'il soit possible de le voler est une chose (à mon avis pas gênante),
qu'il soit possible de le générer soi même pour obtenir un accès (même
minime) est plus gênant : il suffit d'avoir un secret lié à l'id_auteur et
de mettre dans le cookie id_auteur@login@secret ?

Non, du tout. Je pensais aux problématiques de traçage (avec les logs
HTTP ou en sniffant => "tiens, l'auteur numéro 15 qui est Antoine Pitrou
a contribué tel message dans les forums sous tel pseudo ridicule"). Bon,
ce serait la cerise sur le gâteau si on pouvait éviter ça, m'enfin

a+

Antoine.

fil · Juin 6, 2002, 11:18

le secret site est dans les métas (donc accessible immédiatement), pour le
secret auteur je ne vois au contraire pas trop comment faire sans la base.

tu hashes l'id_auteur, et tu stockes 256 secrets dans un fichier texte !
(joke)

Ceci dit pour l'unique problème du rejeu après déconnexion, il suffit
d'effacer toute trace de la session. Comme on choisit un cookie session
différent la fois suivante, l'ancien est totalement inutile. (je fais
peut-être une erreur, là, mais il est tard ;-))

A ce compte-là, pourquoi ne pas donner un cookie carrément random et
totalement jetable ? On n'est pas en train de se casser la tête pour rien ?

Non, du tout. Je pensais aux problématiques de traçage (avec les logs
HTTP ou en sniffant => "tiens, l'auteur numéro 15 qui est Antoine Pitrou
a contribué tel message dans les forums sous tel pseudo ridicule"). Bon,
ce serait la cerise sur le gâteau si on pouvait éviter ça, m'enfin

En général les logs http ne tracent pas les cookies.

-- Fil

63438612493668b99328 · Juin 6, 2002, 11:17

Fil wrote:

A ce compte-là, pourquoi ne pas donner un cookie carrément random et
totalement jetable ? On n'est pas en train de se casser la tête pour rien ?

Heu, c'est à peu près ce que je disais en fait (dans ce message-là, pas
celui de cet après-midi). Mais le mécanisme pour vérifier la validité
du cookie est identique.

Nicolas_Hoizey2 · Juin 7, 2002, 9:14

Hello,

je vois que ça bosse dur, les commit affluent ...

Il me semble que tant qu'à gérer des accès côté public, autant le
faire à fond, c'est à dire avec la possibilité de mettre des
restrictions en lecture par rubrique, en cascade comme pour les
administrateurs locaux côté privé.

Les admins restreints c'est une très mauvaise solution, pitié !

Pourquoi donc ? Je trouve au contraire cela très utile, pour le
principe fonctionnel, même si ce n'est pas forcément parfaitement
codé.

C'est certe plus compliqué, mais cela devrait couvrir tous les
besoins.

C'est pas vraiment la philosophie spip...

Oui, je sais bien.

Mais vu le nombre d'utilisateurs de SPIP qui ont ce même besoin de
restrictions d'accès, ne serait-il pas pertinent de proposer une
solution très riche et flexible ?

- une catégorie de mots clefs nommée 'auth' contient des noms de
groupes, par exemple : 'visiteur', 'commercial', 'admin', ...

Ca ne marche que parce que tu veux restreindre par mots-clés : moi
je veux restreindre par {age_redac}, par exemple...

OK.

- tout utilisateur peut faire partie de 0 à n groupes, ces
répartitions de groupes étant gérées pour l'instant hors de SPIP

Donc : attribuer les mots-clés sur des auteurs...

En effet.

if ([(#ID_ARTICLE|auth_link_article)]) {

eurk !!

Oui, je sais, j'ai bien précisé qu'on fait comme ça (et encore, on
change, finalement) parce que l'on veut conserver la compatibilité
avec les évolutions de SPIP, donc on patche le code le moins possible.

Il est bien entendu hors de question que ce soit géré comme ça par
SPIP le jour où ce sera fait.

[...] cache dont les délais doivent être systématiquement à 0

Pas bon du tout.

En effet, d'où la modif de fonctionnement que nous sommes en train de
faire :

<BOUCLE_derniers_articles(ARTICLES){...}>
 <?php
 if (auth_link_article(#ID_ARTICLE)) {
 ?>
 
 <a href="#URL_ARTICLE">#TITRE</a> 
 #DESCRIPTIF
 
 <?php
 }
 ?>
 </BOUCLE_derniers_articles>

Là c'est bon, l'appel est dans le cache final et non dans sa
génération par appel au squelette.

Amha c'est pas la bonne direction : je crois qu'il faut augmenter un
peu le nombre de statuts possibles pour les auteurs
0 = admin [validation]
1 = redacteur [acces a ecrire]
2 = visiteur [acces authentifie dans l'espace public seulement]
et faire avec.

Je pense que c'est trop restreint, là. D'autre part, il est plus
simple à priori de vérifier des droits par '<' ou '>', donc les id
devraient être inversés. Je verrais donc plutôt :

4 = administrateur (tous les droits)
3 = rédacteur en chef (validation)
2 = auteur (accès à 'ecrire/')
1 = visiteur authentifié
0 = visiteur non authentifié

La protection se ferait avec une simple interdiction pour ceux dont
le statut n'est pas suffisant : restriction='authentifie,0,1'
indique que si (
$visiteur_authentifie AND
$visiteur_authentifie->statut = 0
ou $visiteur_authentifie->statut = 1
) ça passe. Tout reste dans le cache.

Donc ici, il suffirait de faire
$visiteur_authentifie->statut >= 2

-Nicolas