[spip-dev] Developpement Spip et docs

Dev
1

Bonjour,

je suis actuellement en train de développer une 'extension' à
Spip afin de gérer une partie 'privée' (autre que celle des
rédacteurs) contenant des éléments (rubriques, articles, ...)
accesibles uniquement après un login.

Techniquement, l'idée n'est pas vraimment difficile à
réaliser : la visibilité est gérée au niveau des rubriques
(ajout d'un champ visibilité dans la table des rubriques) et
s'applique à tous les éléments contenus dans la rubrique. Il
suffit ensuite d'ajouter ce critère à la construction des
requètes SQL liées aux boucles et normalement le tour est
joué. Bien sur il faut aussi ajouter le système de login et
poser un cookie (pas de session pour rester compatible avec
php3) chez les utilisateurs logés pour activer l'affichage des
rubriques 'privées' et de leur contenu. A priori rien de bien
sorcier, d'ailleurs j'ai déjà écrit une bonne partie du code.
La partie 'administration' correspondante devra permettre de
choisir (simplement avec une checkbox) la visibilité de chaque
rubrique et éventuellement de supprimer/rajouter des
utilisateurs (je n'ai pas encore attaqué cette partie par
contre).

J'essaie de faire ça le plus proprement posssible afin qu'une
éventuelle intégration a spip (v1.4, 1.5 ?) soit possible sans
trop de problèmes. Je me pose toutefois quelques questions :

1- Existe-il une doc expliquant les fonctionnalités
des 'fichiers de fonctionnement' de Spip (ie. ceux de
construction du squelette en php, ...). Actuellement j'essaie
de deviner ce que fait chaque fichier mais ce n'est pas
toujours facile, ou plutôt c'est relativement long et
fastidieu... De plus j'aimerai éviter de 'poser' des fonctions
à des endroits auxquels elles ne correspondent pas vraimment.

2- Performances : pour tous les éléments, sauf les rubriques,
cette modification va entrainer une jointure dans la requète
SQL (pour vérifier la visibilité de la rubrique mère) de la
boucle spip associée, la rendant ainsi plus lourde. Si ça
risque de ralentir un peu le fonctionnement, ça ne devrait a
priori pas être significatif mais je préfère demander l'avis
des développeurs pour être sur.

3- Voyez-vous des points que j'aurais négligé dans la
conception du système? Des problèmes potentiels que je
n'aurais pas détectés ? J'ai découvert Spip il y peu (1
semaine en fait) et il est bien possible que certaines
subtilités m'échappent...

4- Ce système interesse-t-il quelqu'un d'autre ? C'est pour
savoir s'il est utile de passer un peu de temps à réaliser un
package d'installation bien propre et à le tester. Je sais que
c'est fortement conseillé dans la rubrique 'participer au
dvp', mais si je suis le seul à utiliser cette fonctionnalité
ça présente alors peu d'intéret.

5- La question ultime : y-a-t-il quelqu'un d'interessé pour
participer ? En particulier au développement de l'interface
d'administration, qui ne me motive pas particulièrement :slight_smile:
(actuelllement je fait ça avec des requètes 'update' à la
main, c'est pour dire !).

Si vous êtes interessés ou si vous avez des questions,
contactez moi !

d'avance merci,
a+

Pierre Rust

PS : j'ai déjà posté un message à ce sujet sur la ml des
webmestres mais a priori celle-là est plus adaptée.

"Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13 €/mn) ; tél : 08 92 68 13 50 (0,34€/mn)"

2

Hello,

Bien sur il faut aussi ajouter le système de login et poser un
cookie (pas de session pour rester compatible avec php3)

C'est quoi cette histoire ??? Rien n'empêche d'utiliser des sessions
avec PHP3, ce n'est pas parce que PHP4 propose un mécanisme intégré
que c'est compliqué à faire avec PHP3.

L'utilisation de sessions permet de mieux garantir la sécurité.

Nicolas.

3

Note: la version 1.4 (en début de développement) ajoute la possibilité d'attribuer des mots-clés aux rubriques. Il me semble donc qu'il deviendrait possible de gérer ces "rubriques réservées" avec des mots-clés, sans devoir modifier la structure de la base de données.

Le problème de ce genre de chose n'est pas dans la protection des rubriques, mais bien dans la gestion des autorisations: qui peut accéder à quoi. Et là, le risque est très grand d'obtenir une usine à gaz ingérable et incohérente. En effet, il y a déjà un système d'accès privé dans SPIP (les rédacteurs, les admins): si on ajoute une gestion séparée d'autorisations pour les rubriques, le truc risque de devenir totalement incompréhensible.

ARNO*

4

Pourquoi ne pas faire un truc général ? Voici ma proposition, **il se
trouve qu'elle n'affecte en rien spip existant** (je précise que j'utilise
déjà ça sur http://MondeDiplo.com/ )

Il faut à mon avis :

1) une fonction quelconque permettant de savoir si le visiteur est ou non
"accrédité" pour telle ou telle partie du site, par exemple, dans
mes_fonctions.php3 :

    function visiteur_accredite($zone) {
        if ($HTTP_HOST == "145.3.45.2")
            return true;
        else
            return false;
    }

(ici on n'utilise pas $zone, qui servira à gérer plusieurs zones
requérant des accréditations différentes)

2) dans le squelette, deux lignes de php :

    <? if (visiteur_accredite()) { ?>
    blah blah
    <? } ?>

n'affichera blah blah que pour les accrédités. Tout ce qui est au niveau de
blah blah est donc ci-dessous une boucle "privée", ce qui est en-dehors une
boucle "publique".

3) dans la structure du site, on peut décider ensuite des liens
accréditation/contenu, par exemple :

    a) un secteur sur accréditation (secteur 2)
        boucles "publiques" : ajouter {id_secteur!=2}

    b) un mot clé "article sur accréditation" (id_mot = 5)
        boucles "publiques" : ajouter {id_mot!=5}

    c) les archives des articles les plus anciens (un an) seulement sur
        accréditation ?
        boucles "publiques" : ajouter {age<365}

Evidémment, dans tous les cas on met ce qu'on veut dans les boucles privées,
mais a priori ce sera la négation du critère utilisé dans les boucles
publiques.

4) Il faudrait maintenant se mettre d'accord sur la fonction
visiteur_accredite() : mais est-ce possible ? Sur http://MondeDiplo.com/
l'accréditation se fait par demande d'un mot de passe via http 401.
Sur d'autres sites c'est un formulaire qui pose un cookie. Ailleurs ce sera
en fonction du numéro IP, etc. L'idéal serait d'avoir une bibliothèque de
telles fonctions, à utiliser en fonction des besoins.

PS: parfois il faut être patients, on n'est pas toujours à spiper comme des
fous, chacun de nous a aussi un "day job".

-- Fil

5

Bonsoir,

4) Il faudrait maintenant se mettre d'accord sur la fonction
visiteur_accredite() : mais est-ce possible ?

Il en faudrait une par défaut, dans "inc-auth-spip.php3" par exemple,
mais qui puisse être remplacée par une autre définie par exemple dans
un "inc-auth-ldap.php3" par l'admin, le tout étant géré par un
"inc-auth.php3" comme c'est déjà le cas avec les "inc-url*.php3".

Nicolas.

PS: A propos de tous ces fichiers, qu'est-ce qui justifie qu'ils
    "encombrent" la racine au lieu d'être dans 'ecrire/' ou, encore
    mieux, dans 'ecrire/include/' ?

6

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

PS: A propos de tous ces fichiers, qu'est-ce qui justifie qu'ils
    "encombrent" la racine au lieu d'être dans 'ecrire/' ou, encore
    mieux, dans 'ecrire/include/' ?

Rien.

-- Fil

7

Nicolas Hoizey wrote:

PS: A propos de tous ces fichiers, qu'est-ce qui justifie qu'ils
    "encombrent" la racine au lieu d'être dans 'ecrire/' ou, encore
    mieux, dans 'ecrire/include/' ?

Dans ecrire, ils encombreraient encore plus, alors qu'actuellement
on sépare les fichiers de l'espace public de ceux de l'espace privé.
Il vaudrait mieux créer un répertoire du type public/. Mais certains
fichiers doivent rester à la racine (spip_*.php3), ça ne va pas tout
nettoyer.

a+

Antoine.

8

Yop. Au passage, petite explication sur ces fichiers qu'on ne peut pas déplacer dans /ecrire ni dans un autre dossier... Certaines fonctionnalités accèdent à des dossiers, en particulier /IMG et /CACHE. Or certains serveurs (Altern, je crois bien) interdisent les chemins relatifs "remontant" d'un niveau. Du coup, certaines opérations doivent impérativement être effectuées depuis des fichiers installés à la racine du site. De fait, même certaines opérations de l'espace privé sont réalisées par des scripts installés à la racine: installer des logos et des images dans l'espace privé commande en réalité un script installé à la racine, qui seul pourra accéder à /IMG. Egalement, poser le cookie depuis l'espace privé se fait à la racine, cette fois-ci parce que certains butineurs attribuent le chemin de l'URL, et pas seulement la racine du site; du coup un cookie posé depuis /ecrire n'était pas actif à la racine du site...

ARNO*

9

Hello,

Dans ecrire, ils encombreraient encore plus, alors qu'actuellement
on sépare les fichiers de l'espace public de ceux de l'espace privé.

Mais n'y a-t'il pas des doublons entre '/' et 'ecrire/' ? Ne serait-il
pas possible de factoriser plus proprement le code ?

Nicolas.

10

Nicolas Hoizey wrote:

Mais n'y a-t'il pas des doublons entre '/' et 'ecrire/' ? Ne serait-il
pas possible de factoriser plus proprement le code ?

Oh oui, certainement ! Mais ces doublons ne sont pas dus à la structure
de répertoire puisque l'espace public appelle déjà des includes dans
ecrire/ ;))

Surtout, le code le plus bordélique se trouve dans l'espace privé.

11

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

Mais n'y a-t'il pas des doublons entre '/' et 'ecrire/' ? Ne serait-il
pas possible de factoriser plus proprement le code ?

Je ne crois pas.

Quand un fichier dans / a besoin d'une fonction, en général il inclut le
fichier ecrire/inc_... correspondant. La seule fonction, à ma connaissance,
qui soit définie dans les deux est celle qui azffiche les images d'articles
(car elle ne fait pas exactement la même manip, celle d'ecrire/ n'ayant pas
accès à la liste des images présentes dans IMG/ )

-- Fil

12

Yop. Au passage, petite explication sur ces fichiers qu'on ne peut
pas déplacer dans /ecrire ni dans un autre dossier...

Merci.

Certaines fonctionnalités accèdent à des dossiers, en particulier
/IMG et /CACHE. Or certains serveurs (Altern, je crois bien)
interdisent les chemins relatifs "remontant" d'un niveau. Du coup,
certaines opérations doivent impérativement être effectuées depuis
des fichiers installés à la racine du site.
De fait, même certaines opérations de l'espace privé sont réalisées
par des scripts installés à la racine

Donc on fait un "redirect" vers un fichier de la racine, puis un
nouveau "redirect" vers le fichier vu par l'utilisateur ??? Zarb, mais
pourquoi pas ...

poser le cookie depuis l'espace privé se fait à la racine, cette
fois-ci parce que certains butineurs attribuent le chemin de l'URL,
et pas seulement la racine du site;

Et ils font bien si le paramètre 'path' n'est pas donné au cookie,
justement. Donc là c'est à priori une mauvaise excuse, désolé ... :wink:

Nicolas.

13

Quand un fichier dans / a besoin d'une fonction, en général il
inclut le fichier ecrire/inc_... correspondant.

Alors parfait, je n'ai rien de plus à ajouter sur ce sujet ... :wink:

14

Et encore ? Soit plus explicite..

A.