Les évolutions à venir
A titre d’explications sur les travaux à venir sur ce sujet, ci-dessous la reprise d’un post de Cedric sur spip-zone.
De : Cedric
Date : 26 mai 2007 15:38:34
Cc : spip-zone@
Les deux démarches sont incomplètes. Il faut donc les mettre en commun pour avoir :
- les zones d’accès, que l’on définit bien unitairement comme actuellement (par rubrique, mais pourquoi pas par article dans le futur)
- les profils, qui sont un ensemble d’autorisations d’accès à des zones, mais pourquoi pas aussi d’autres autorisations, comme pouvoir modifier un article publié précis ou autre)C’est bien avec ces deux concepts que l’on aura toute la souplesse et la clarté recherchées.
Cedric
Travaux préparatoires coté documentation
Pour préparer la suite de l’évolution du code les deux plugins on été regroupés dans une rubrique-dossier commune. L’idée est de préparer un support pour pouvoir commencer à rassembler tout ce qui peut se dire sur le sujet, histoire de faciliter la réalisation de la future documentation.
N’hésitez pas à utiliser le présent forum par exemple pour les questions et notes, ou à proposer de nouveaux articles.
Rappel des objectifs du chantier (mise à jour 3 juin 2007)
Il est (re)précisé que l’objectif de ce chantier est bel est bien de faire ce qui est défini dans le mail de Cedric ci-dessus, ni plus ni moins (sauf si les auteurs en décident autrement bien sûr).
Les réflexions plus générales sur la gestion des droits et les processus de validation de SPIP sont certainement utiles, mais elles dépassent le cadre du présent chantier. L’expérience est que ce n’est pas en chargeant d’avance trop la barque de leurs objectifs que les plugins avancent, mais bien au contraire par avancées successives dans un cadre souple, au gré des besoins et de l’imagination de leurs auteurs. N’oublions pas que le présent débat n’est possible que parce que les deux précédents plugins, avec leurs limites maintenant analysées, on été créés d’abord .... voir aussi ce post à ce propos http://www.spip-contrib.net/Acces-r...
Un petit état des lieux est mis en débat sur ce post (6 février 2008)
Mise a jour du 13 janvier 2009
La version 3.0 du plugin Acces Restreint pour SPIP 2.0 est disponible ici Acces Restreint 3.0.
Ce plugin n’intègre pas les fonctionnalités d’accès restreint par groupe, mais est une évolution du plugin Accès Restreint, du point de vue ergonomique et performances.
Discussions par date d’activité
18 discussions
Je vois plusieurs messages qui parlent de listes d’utilisateurs.
Les 2 plugins existant s’appuient sur le système d’authentification de SPIP et ça me semble une bonne chose.
Les utilisateurs sont soit entrés dans la base des comptes internes , soit extraits depuis un annuaire LDAP.
La mise en place d’un base de compte externes reste possible via le développement d’un plugins qui surchargent le mécanisme d’authentification. Mais il me semble qu’il faut garder le fonctionnement actuel : le plugin accès restreint n’est pas là pour gérer sa propre base d’utilisateur, il va juste ajouter des profils dans « l’annuaire » interne de SPIP.
a+
Répondre à ce message
Où en êtes vous du développement de la version 2 du plugin ?
Existe t’il une version alpha ou beta à tester ?
Ou vaut t’il mieux pour le moment s’en tenir à gestion par groupe ou accès restreint en fonction de l’utilisation finale souhaitée (Entreprises privées, ou établissements public (collège, lycée, mairie, ect...) ?
Ce plug in sera t’il compatible avec les différents plug-in squelette comme par exemple le squelette sarkaspip ?
Le testez vous avec des plugins d’éditeurs WYSIWYG tel fckeditor ou tinyMCE ou DOJO ?
Un import des utilisateurs sera t’il intégré dans votre plug in ou bien il s’interfaçera avec d’autre plug in comme par exemple csv2spip.
Merci de votre réponse.
Bon courage pour la suite de votre projet (certains partent à la plage bronzer et d’autres restent devant leurs claviers afin d’aider les autres à la rentrée :-).
Répondre à ce message
une petite réflexion...
Deux façons de faire un héritage sur les droits d’accès.
1) un lien entre une table profil et l’auteur.
2) une copie du profil dans une table droit auteurs.
dans le premier cas, une modif des droits du profil est directement reportée sur les utilisateurs du profil.
dans le deuxième cas, il est possible d’affecter un profil puis d’ajouter / supprimer des accès spécifiquement. (sera-t-il possible de garder en mémoire l’origine de l’héritage... profil (lequel) ou direct ???)
LA question principale étant : Voulons nous pouvoir restreindre / étendre ponctuellement les droits d’un utilisateur lié a un profil. (Le profil est-il un modèle ?)
Répondre à ce message
Il me semble important avant que le développement de Accès Restreint V2 ne soit lancé que les points suivants puissent être éclaricis :
Cordialement à tous
Du point de vue d’un utilisateur qui ne veut pas savoir comment ça marche à l’intérieur :
- Je ne pense pas qu’il soit nécessaire d’avoir de vrais points de sortie d’une branche, je crois que ça serait plus déroutant qu’autre chose d’avoir une sous-branche non protégée (ou moins protégée). Je pense en particulier au chemin d’accès (fil d’ariane), à l’affichage des rubriques qui ne fonctionne pas puisque le point d’entrée n’est pas accessible, etc.
- Par contre, je pense qu’il est important de pouvoir définir des restrictions supplémentaires dans une sous-branche. L’accès à cette sous-branche serait alors restreint à l’intersection des utilisateurs (ou groupes, ou profils...) appartenant aux deux zones. On garderait ainsi le principe des « portes » de la V1 : il est nécessaire de pouvoir ouvrir la première porte pour ouvrir les suivantes ; en revanche ce n’est pas forcément suffisant.
- En ce qui concerne l’accès aux documents, je pense aussi qu’il est nécessaire de pouvoir restreindre l’accès aux documents attachés aux articles et rubriques. Je ne pense pas qu’on doive avoir à gérer des permissions différentes pour le document que pour l’article auquel il se rattache, en tout cas dans un premier temps. Par contre, ça devrait gérer aussi les images, ainsi que leurs éventuelles miniatures et transformations.
En espérant que ça puisse vous faire avancer...
Parler de points de sortie ou de surprotection d’une sous-branche sont en fait de manière différente de présenter un même problème. Il est certain en effet que parler de restrictions supplémentaires est plus facile à saisir conceptuellement.
Nous sommes d’accord en tout cas sur l’image des verrous, où pour arriver à une rubrique il faut etre en capacité de passer tous les verrous posés sur le chemin depuis la racine.
Répondre à ce message
oups, je viens de voir la mise au point sur les objectifs du débat.
Désolé.
Je m’en vais continuer ma réflexion dans mon divan.
Bon travail.
Répondre à ce message
Bonjour,
D’abord, je salue l’initiative (ouvrir ce forum sur l’évolution d’un plugspip).
Voici ma petite contribution à la discussion :
- vu que la question de la gestion des droits est une une question de fond (c’est pas un « gadget »), à tout point de vue ;
- vu qu’à mon avis la future squelettisation de l’espace privé conjointement à l’apparition de plugins permettant la publication totale ou partielle de contenu via l’espace public conjointement à la montée en puissance de l’utilisation de jQuery et de ses possibilités en matière d’Ajax ... va conduire à l’atténuation de la différence entre espace privé et espace public ;
- vu que le travail en cours sur spip 1.9.3. et celui sur un spip 2.0, doit sans doute comporter des éléments (fonctions) plus qu’utiles à une gestion avancée des droits ou des pistes (pour la 2.0) de travail quicommencer à se concrétiser ;
- vu que la question de gestion des droits est articulée fortement à celle de workflow ;
- vu que cette question du (des) workflow va s’avérer bientôt aussi essentielle que celle d’une gestion des droits (pas seulement d’accès, d’ailleurs) ... suffit de voir les plugs qui apparaissent ou s’annoncent et qui touchent à cette question ;
- vu qu’il m’étonnerait que les dev. du core de spip ne planchent pas aussi d’une manière ou d’une autre sur la question (parce que fondamentale, quoi qu’on en pense principiellement)
est-ce qu’il ne serait pas utile d’envisager d’emblée que cette page élargisse ses ambitions en vue de favoriser l’émergence
1/ d’un groupe de travail (si possible conseillé, voire cornaqué par les développeurs du core de spip) chargé spécifiquement de mettre au point un module de gestion avancée de droits, selon un modèle préalablement discuté et un cahier de charge tout aussi préalable et discuté, destiné dès le départ à être intégré au core. Eventuellement après prototypage sous la forme d’un plugspip.
Ce serait - qui sait - un nouveau (oui ? non ?) modèle de travail collaboratif à tester pour le développement du core de spip.
2/ d’étendre la question à celle des workflows.
à ta lecture il m’apparaît que lies administrateurs restreints relèvent de la même logique. En effet, il s’agit d’une restriction de leur droits d’administration à certaines branches.
Ta suggestion serait donc une réflexion globale sur les différents droits possibles à savoir :
- accès aux éléments publiés (grosso modo l’accès public)
- accès aux éléments proposés à publication (grosso modo une sorte d’accès privé)
- autorisation de proposer de nouveaux éléments à publication (rédacteur)
- droit de corriger les éléments proposés à publication
- validation des éléments proposés à publication (admin restreint)
- gestion globale des publications du site (admin général)
- gestion globale du site, des plugins, des fichiers, des sauvegardes (webmaster)
Bien sur, cette liste n’est pas exhaustive car il faudrait également détailler la gestion des forums, des mots clés et des auteurs.
Les droits d’un auteur devraient pouvoir dépendre d’où l’on se situe dans l’arborescence du site et il faudrait pouvoir spécifier, pour un même auteur différents niveaux de droits en différents endroits de l’arborescence.
D’autre part, il faut pouvoir tenir compte d’arborescence complexe et la définition de droits ne peut pas porter uniquement sur des branches. Il faut pouvoir gérer un secteur membres avec une sous rubrique bureau où un auteur peut avoir certains droits dans membres mais pas dans bureau.
Bonjour,
les plugins touchant à la gestion des droits et workflow commencent à devenir nombreux : gestion de la licence de l’article par l’auteur, plugin Autorité, les 2 plugins suscités et probablement d’autre.
En matière de workflow, une limitation parmi d’autres est que les administrateurs ne peuvent pas définir par exemple un groupe de travail à un article ou permettre à un auteur de reprendre un article soit en cours de rédaction (mais ayant besoin d’une tierce personne pour pouvoir être jugé bon à la publication), soit un article ancien jugé obsolète mais pouvant être retravaillé par un auteur plus récent. Après tout dans les rédactions de type magazine papier, un article peut passer entre plusieurs mains avant d’être validé, que ce soit pour de la correction orthographique ou typographique, ou que ce soit de la vérification et de l’amélioration du contenu.
On peut ainsi imaginer la possibilité de définir des groupes ayant certains droits de modifications par lesquels certains types d’articles (ces articles étant filtrés par mots-clefs, par rubrique, par secteur) devraient transités avant de pouvoir être mis en ligne.
Bien que les forums internes permettent déjà de donner son avis et donc laisse l’auteur maitre de son article, il manque quelques possibilités éditorials pour avoir réellement un « mécanisme de workflow ». Cependant de telles fonctions ne sont clairement pas intéressantes pour chaque site et donc sont vouées à rester sous forme de plugin.
Voilà les maigres réflexion qui me sont venu en lisant succinctement vos réflexions.
En ce qui me concerne je suis certain que si on ne garde pas la souplesse de la méthode actuelle du bordel organisé je ne ferais certainement pas partie de ce « groupe de travail »...
Sûr que l’idée d’être « cornaqué » ne me plaît *vraiment* pas et que le modèle de travail collaboratif existant est le seul dans lequel je me retrouve !
En clair : ne pas oublier qu’avant tout les devs de plugins le font pour leur *plaisir* et que multiplier les contraintes et rigidifier le cadre dans lequel ils évoluent risque de faire fuir nombre d’entre eux vers des horizons plus « libres » !
Pour mémoire, SPIP c’est « du logiciel libre et de la tendresse » alors n’abusons pas de gros mots tels que « workflow », « cahier des charges » ou « prototypage »... :-)
Enfin, quand au point « destiné dès le départ à être intégré au core » tu semble oublier que la tendance est à l’amaigrissement de ce même core en externalisant le maximum de choses en tant que plugin... Alors dans le cas précis de la restriction d’accès vu le nombre de sites qui n’auront jamais besoin de cette fonctionnalité, ça ne me paraît ni urgent ni souhaitable !
:-)
Me suis mal fait comprendre.
Je précise : je suis plutôt anarchiste libertaire ... donc pas de procès d’intention. Je ne propose pas de mettre au pas quoi que ce soit ...
Je pars juste d’un constat :
- le core s’amaigrit et passe une série de fonctions vers des plugs ... ok mais quand je vois les problèmes des plugs pour suivre l’évolution du core et rester compatibles avec lui et entre eux, je crois qu’il y a moyen d’être un peu plus efficace (c’est un gros mot ?). Pour bien me faire comprendre, je ne dis PAS que ces problèmes sont anormaux et révèlent une défaillance grave dans spip et son mode de fonctionnement collaboratif, je dis qu’à bien lire les posts des devs de plugins, ce qu’ils disent, les types de problèmes, etc. il m’apparaît assez clairement que cet effort d’externalisation mené par les dev. du core qui font ça pour leur plaisir et sans contrainte manque quand même un peu du minimum d’« exposition » méthodologique pour que tout le monde puisse suivre sur une base mutuelle ;
- tout le monde fait ça pour son plaisir ... non c’est pas vrai : il y a là des gens dont c’est « en partie » le business et qui NOUS FONT le plaisir - partagé sûrement - de mettre en commun le fruit d’un labeur inscrit au moins pour une part dans le champ des échanges marchands ;
- es-tu absolument sûr qu’un espace où chacun est libre d’entrer (liiiiiiibre) mais qui implique le respect de certaines règles complémentaires au joyeux bordel organisé ne peut pas être un dispositif où le plaisir se déploiera aussi intensément que dans un joyeux bordel ;
- développer un plug pour des fonctions importantes, touchant au coeur du modèle d’un cms, demande un investissement temps important et des connaissances durement acquises (de spip notamment). Il y a des codeurs d’enfer ici. Et souvent, ils se lancent dans une aventure pour trouver une réponse à un besoin personnel et spécifique. OK. A partir de là, comment peux-tu préjuger qu’aucun d’entre eux ne serait intéressé par un espace avec une méthodologie de développement collaboratif un peu plus organisée,
1/ qui aiderait à une meilleure coordination au niveau d’une définition de chantier préalable ;
2/ qui pourrait être, même de très loin, suivie par un dev du core - ne fut-ce pour pour prévenir (par exemple d’une future évolution de tel fragment de code dans spip, ou d’un changement majeur etc.) ou aider (par exemple à trouver le bout de code spip sur lequel appuyer telle nouvelle fonction).
Ceci étant, moi ce que j’en dis ...
Maintenant, je vais t’avoquer deux petites choses :
1- j’ai développé des morceaux de code pour des sites spip ... à côté de spip, parce que c’était tout simplement plus rapide de squizzer le core de spip (pour ce que j’avais à faire) que de m’appuyer dessus. Aucun intérêt donc à mettre ça sur la zone. Je nai malheureusement pas le temps de plonger dans une doc « dev » éparpillée pour l’essentielle dans le code et dans les changeset et tenter de reconstituer le futur de spip à travers les bribes échangées à ce sujet sur la liste spip-dev. Un espace collaboratif (pas le seul, parmi d’autres, où chacun serait liiiiiiiiiiiibre d’entrer ou non) plus contraignant quant aux méthodes de travail aidera peut-être à constituer une base de conniassance orientée « dev », centralisée, cohérente, corrigée et à jour ... Peut-être seulement, je précise, c’est pas sûr.
2- J’ai imaginé que l’allègement du core de spip pourrait bien passer par
la pluginisation de l’espace privé (mis à part l’espace - les espaces - d’administration et de réglages). Je vais donc plus loin que la simple squelettisation des espaces d’édition (encore que la pluginisation a besoin de la squelettisation),
- et (encore plus fort) par la pluginisation des tables à « contenu éditorial » (articles, rubriques, etc.), ne gardant que le « moteur », susceptible de s’appliquer à tout contenu « tables d’une base de données ». Un contenu structuré par rubriques, brèves et articles, avec mots clés, n’étant qu’un plugin à destination d’un usage particulier. Plugin « standard », pourquoi pas ...
Ce qui m’amène à penser par contre que la capacité à gérer un workflow (sa définition opérationnelle pouvant relever d’un plug) et la capacité à gérer un système un peu complet de droits (par exemple de type RBAC ou ORBAC) relèvent d’un ensemble de fonctions et d’une architecture qui ont, elles, plutôt place dans core, non ?
C’est un hommage que je rends à spip : arrivé à ce stade développement, au potentiel que son moteur lui donne, à la qualité des dév. du core, ... est-ce « déplacé » de trouver que le joyeux bordel (dev de plugs) qui consiste quand même à 70-80% à fabriquer, coller et remplacer des rustines, même avec beaucoup de talent, d’ingéniosité et d’esprit convivial et partageur, n’est peut être pas le seul modèle, exclusif, à envisager.
In fine, personnellement, je n’arrive pas à m’investir dans spip - alors que j’aimerais beaucoup, parce que je n’ai pas le cadre « collaboratif » pour le faire. Au contraire de toi.
Spip contrib n’est PAS un cadre collaboratif, il est un dispositif de mutalisation et de partage. C’est pas la même chose. Le wiki pouvait être un espace collaboratif, mais j’apprends qu’il est prévu de l’euthanasier pour le ramener vers spip-contrib (ou alors j’ai encore une fois rien compris).
et donc ...
Répondre à ce message
Deux bons projets en effet !
Le sujet m’intéresse beaucoup et depuis un bout de temps. Dans un développement parallèle à Gestion de groupe pour Spip 1.8.3, j’ai ajouté une notion de Profil d’auteur et de profil par administrateur qui permettait de limiter les droits d’un nouvel auteur en fonction de l’administrateur qui le criait.
Cette caractéristique a un sans en autant qu’on autorise un administrateur restreint à créer un auteur. Par exemple, un professeur qui est administrateur restreint d’une rubrique pour ça classe peut créer ces élèves comme rédacteur. Ces derniers ne peuvent écrire par défaut que dans les rubriques gérées par leur professeur.
Le profil d’un auteur a également une date d’activation et une date d’expiration. On peut donc donner à un élève une date limite ou son accès sera automatiquement suspendu. Son « parrain » ou administrateur responsable ayant aussi une date limite, cette date peut être prioritaire sur la date personnelle d’expiration.
Je n’ai pas regardé depuis un bout de temps les détails du plugin Gestion de groupe. Est-ce qu’il existe quelque chose du genre ?
Un autre point, dans un travail d’adaptation d’une contrib permettant la gestion des accès par mot clé, j’ai réussi à contourné le besoin de modifier les squelettes comme le demande actuellement Accès restreint si on veut que les pages à accès limité n’affiche pas de page blanche : en gros, lorsqu’on appelle un article par exemple, la page article.html contenu dans le plugin a priorité sur la page article.html du squelette du site. Si la l’accès à la page n’est pas autorisé, on affiche une page de login. Une fois identifié, la page article.html original est utilisée normalement et l’article est affiché. Donc, oui, la page article.html du plugin appelle la page article.html du squelette et ce par un inclure ! L’objectif était ne pouvoir activé le plugin, de ne pas avoir de page blanche si la page est protégé sans avoir à ajouter la moindre ligne au squelette pour ce faire.
L’astuce est simple : le plugin contrôle l’ordre de priorité des dossiers squelettes pour dans un premier temps rendre ses pages prioritaires et dans un second temps (lorsque notre page article.html appelle la page article.html original) restaure l’ordre naturel.
En plus, j’ai ajouté deux points d’entrée du style pipeline dans la fonction de vérification des droits d’accès afin de surcharger celle-ci pour permettre de personnaliser ses options de gestions.
L’idéal serait, selon moi, d’isoler totalement la fonction de contrôle de l’affichage dans l’interface privée et public des fonctions de gestion de ces droits. Ainsi, il serait possible de personnalisé les critères d’accès, de combiner plusieurs systèmes de gestion d’accès sans conflit.
Je continue de travailler sur mon plugin de mon côté pour garder la compatibilité ascendantes pour mes clients. Mais je trouve l’idée d’intégrer ces deux plugins des plus logique.
Bref, si certaines idées peuvent servir, je reste disponible pour aider.
Répondre à ce message
Bonjour,
Bravo pour cette initiative.
Il faudrait aussi essayer de mettre en place un accès par adressage IP, comme je l’avais mentionné précédemment.
J’avais posté un bout de code qui semble fonctionner (tester...).
A bientôt
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
