Accès restreint V2 - Les objectifs

Attention, cette contribution est EN CHANTIER : elle n’est peut-être pas fonctionnelle.

A partir de l’expérience accumulée sur « Accès restreint » et « Accès restreint par groupe », le constat de la nécessité d’une fusion des deux plugins..

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.

Discussion

18 discussions

  • Bonjour,
    Personne n’a un truc concret pour la protection des documents joints ?
    Un htaccess ? pour une double authentification ?
    Merci de votre aide

    Répondre à ce message

  • 1

    Le plugin semble ne pas fonctionner avec spip V2. Est-ce qu’il est prévu de faire une mise à jour du plugin ? Si oui quand (au moins un ordre de grandeur... 1 semaine ? 1 mois ? 6 mois ? 1 an ?).
    Merci d’avance

    Répondre à ce message

  • 4

    Malgré toute la bonne volonté qui sera portée à la mise en place de ce plugin, il y a une chose spécifique à SPIP qu’il ne pourra pas modifier.

    Chaque document téléchargé sur un site SPIP est stocké dans un répertoire donné (/IMG/...) en fonction de son extension (par exemple .doc, .ppt, .xls...). L’authentification actuellement proposée ne restreint que l’accès aux rubriques, pas aux document joints.

    Par exemple, si je vous informe par un biais détourné qu’un document super confidentiel est ici http://www.monsitespip.com/spip/IMG/pdf/docsupersecret.pdf), vous pourrez y accéder sans avoir besoin de vous authentifier, puisque vous avez l’URL directe.

    Tant que cette façon d’accéder aux document n’est pas modifiée, toute volonté de faire de la sécurité me semblera limitée : SPIP pour des documents 100% publics, c’est très bien. Pour des rubriques privées, pourquoi pas. Pour des documents sûrs, non. Enfin, pas encore.

    N.B. : j’utilise SPIP depuis 3 ans, et je suis accro. C’est donc une simple remarque sur la façon de voir les choses.

    • Il y a une solution technique à ce besoin depuis un petit moment déjà, aussi bien dans Acces restreint 2.0 pour SPIP 1.9.2 que dans la version 3.0 pour SPIP 2.0 :
      Il est possible d’activer le filtrage par htaccess. Dans ce cas, toutes les urls de documents passent par un wrapper php qui vérifie les droits. En complement, il suffit de mettre un htaccess sur son répertoire IMG/ pour bloquer les acces directs.

      Mais attention, cette méthode a un cout serveur non négligeable car toutes les url d’images lancent un script php.

    • NOTA BENE :

      Je rajouterais en complément de la remarque de Daniel, sur la possibilité de passer outre les protections mises en place lorsque il s’agit d’un document intégré à une rubrique reservée, qu’il est également possible de récupérer ce même document via le fil d’info du squelette backend.html ou backend-breves.html lorsqu’il n’est pas desactivé.
      Prudence donc surtout si il s’agit de données quelques peu confidentielles.

      Pour palier rapidement au problème il est conseillé de mettre en place une redirection php dans le squelette dans un premier temps puis de supprimer la reference à la balise META dans l’entete de page.

      D’ailleur à voir les quelques sites utilisant l’un de ces modules il semble que les proprietaires aient déjà pris les devants.

      Bref on espère que la mécanique du futur plugin compatible SPIP 2 n’occassionnera plus ce type de frayeurs.

      Et bravo pour le boulot sur ces 2 plugins.

    • En réponse à Daniel pour son post du 15 décembre 20:36 :

      VOIR : http://www.spip-contrib.net/Acces-restreint-V2-les-objectifs#forum411135

      J’ai pu constater ce problème lors de la mise en place de l’intranet de mon établissement qui dans ce cas précis permet la consultation de notations par cycles d’élèves.

      Si l’on s’en tient à définir des noms de fichiers du type « notes_cycle1.pdf » puis « notes_cycle2.pdf » alors dans ce cas rien de plus facile pour les élèves d’un autre cycle de récupérer par déduction des fichiers de notes qui ne les concernent pas.
      Nous avons simplement intégré une chaine de 10 caractères dans le préfixe du fichier pour obtenir « duj4f5d2ss-notes_cycle1.pdf » puis « yhed584tg3-notes_cycle2.pdf »

      La il semble beaucoup difficile de tomber sur le bon fichier du premier coup.

    • Avez-vous une documentation pour la mise en place de ce filtrage.

      Nous travaillons pour un site gouvernemental et la sécurité d’accès aux fichiers joints aux articles est un critère de choix. Nous testons actuellement plusieurs CMS dont SPIP.

      Notre problématique : l’accès aux fichiers doit obéir aux mêmes règles que l’accès aux rubriques. Certains fichiers dans le répertoires ’IMG’ seront accessibles sans authentification (la majorité) mais d’autres nécessiteront une authentification.

      Merci.

    Répondre à ce message

  • 1

    Quelques mise au point à propos de cette V2 tant attendue...

    Non le projet de fusion n’est pas mort mais simplement en « stand-by prolongé » (le temps que je finisse de rénover chez moi histoire d’avoir un endroit pour poser mon ordi avant de recommencer à coder...).

    Non les 2 plugins ne sont pas développés indépendament puisque le système de restriction d’accès_groupes est tiré (pompé ?) des développements de Cedric pour le plugin acces_restreint.

    Par ailleurs le plugin acces_groupe semble présenter un problème en ce moment : lorsque le nombre de groupes/sous-groupes et de niveaux de rubriques/sous-rubriques est grand, le système de filtrage des accès n’ayant pas (du tout) été optimisé au niveau du nombre de requètes dans la base MySQL il génère un nombre totalement abusif d’accès à la base (jusqu’à + de 6000 pour afficher une seule page dixit un utilisateur sur spip-zone) ce qui le rend inutilisable dans ces conditions... La première étape de la fusion sera donc de modifier ce fonctionnement.
    Il faudra également « ajaxiser » les différents éléments de l’interface d’administration d’acces_groupes qui sont pour l’instant désespérément peu ergonomiques en terme de rapidité des opérations (la page est rechargée à chaque ajout d’utilisateur, sous-groupe ou rubrique « interdite »).

    Quand au principe de la fusion, après avoir pas mal réfléchi à la chose (le travail manuel ça laisse du temps pour penser à autre chose...) voici quelques pistes :

    • acces_restreint permet de faire des regroupements de rubriques « interdites » (= « zones ») et d’attribuer des droits d’accès a des utilisateurs mais seulement un par un (circonstance agravante, il faut aller sur la page de chaque auteur que l’on souhaite ajouter à une zone : rédhibitoire si on envisage son utilisation dans un spip avec 2000 utilisateurs)
    • acces_groupes permet de faire des regroupements d’utilisateurs (= « groupes ») et, pour chacun d’entre eux, de définir des rubriques « interdites » aux autres utilisateurs.
      Le point important est que (déja actuellement) dans acces_groupes chaque groupe est associé non pas à une rubrique « interdite » unique mais à un ensemble de rubriques : on retrouve donc là exactement la même possibilité de « zones interdites » que dans acces_restreint... (même si ça ne s’appelle pas une « zone », c’est le même concept)
    • dans les deux plugins les restrictions d’accès associées à une rubrique/groupe de rubriques peuvent concerner l’espace public ou l’espace privé ou les 2.
    • découle des points précédent que l’on peut donc déja avoir exactement les possibilités d’acces_restreint en utilisant acces_groupes... si ce n’est que l’interface d’administration d’acces_groupes est nettement plus lourde et compliquée à utiliser et que la logique d’utilisation est nettement moins intuitive que celle d’acces_restreint
    • en conclusion de ces quelques points, le chantier de fusion (hors des nécessaires optimisations d’acces_groupes citées plus haut) semble donc être d’arriver à un plugin qui propose la possibilité d’attribuer les zones interdites lors de l’édition/création d’un auteur (comme acces_restreint) avec une interface d’administration (la page où sont définies les zones interdites) qui permette également de gérer les accès à ces zone par le système de groupes (cf l’interface d’administration d’acces_groupes).
      Pour faciliter l’utilisation de cette interface d’admin on peut envisager de l’organiser avec la définition des zones en tête de page (i.e. récupérer l’interface actuelle d’acces_restreint histoire de ne pas déstabiliser les utilisateurs actuels de ce plugin) suivie de la partie de gestion des groupes/sous-groupes (i.e. avec exactement les mêmes outils que l’interface d’admin actuelle d’acces_groupes mais organisés différemment dans la page).
    • en ce qui concerne les (nombreuses) fonctionnalités supplémentaires demandées dans ce forum, j’avoue que pour l’instant la seule réponse que j’aurais à faire est : « le SVN est accessible à tous, on testera volontier vos développements lorsque vous aurez fini de les coder ! »

    Sur ce, je retourne à ma ponceuse et ma scie circulaire alors soyez patients...

    • Bonjour,

      Je sais que vous demandez d’être patient, mais ce plugin à venir semble être tellement pratique qu’il est bien difficile d’attendre.

      Est-il possible d’avoir une date approximative de sortie ? Juste pour savoir s’il suffise que j’attende encore un peu ou s’il faut que je me rabatte sur un des 2 anciens plugins (accès restreint V1 ou accès restreint par groupe) en attendant.

      Encore merci pour le boulot réalisé.

    Répondre à ce message

  • 1
    Pierre-Louis

    Bonjour.

    J’utilise actuellement le plugins accès restreint.

    J’ai deux types d’utilisateurs. Les premiers ont accès à une rubrique 1. Les second ont accès à la rubrique 1, mais aussi à la 1.1 .

    Mon problème est le suivant. Bien que je ne coche pas la case de la rubrique 1.1, lorsque je donne, aux premiers utilisateurs le droit de voir la rubrique 1, ils ont aussi accès à la 1.1.

    De ce fait, si j’attribue à des utilisateurs le droit de voir une rubrique, même si une rubrique englobée fait l’objet d’un accès restreint par ailleurs, ces utilisateurs y ont accès.

    Règlerez vous ce détail (IE : Pouvoir refuser l’accès à une sous rubrique même si on autorise l’accès à celle qui l’englobe) ? Ou peut-être n’utilise-je pas correctement le plugin ?

    J’utilise :

    — SPIP 1.9.2d

    — Accès restreint 2.0

    • cy_altern

      ce problème ne se pose pas si tu utilise le plugin accès_groupe : avec ce plugin les utilisateurs autorisés à voir ta rubrique 1 n’ont pas accès à la sous-rubrique 1.1.
      En revanche les utilisateurs autorisés à l’accès de la sous-rubrique 1.1 pourront y accéder MAIS ils ne verront pas la rubrique 1...ni la sous-rubrique 1.1 dans les menus => il faudra donc faire un lien qq part directement sur la sous-rubrique 1.1 si tu veux qu’ils aient un accès à celle-ci via la navigation dans le site.

    Répondre à ce message

  • Bonjour

    Juste une petite demande de précisions. Il est indiqué qu’on constate « la nécessité de fusion des deux plugins », accès par groupes et accès restreint. Pendant un temps, il semblait que le plugin accès par groupes soit un peu laissé à l’abandon, ce qui semblait logique au vu de la phrase ci-dessus.

    Mais actuellement, ce plugin a été mis à jour.

    Est-ce à dire que le projet de fusion est mort ?

    Les deux plugins sont-ils développés de façon indépendante ; le cas échéant, le choix s’avère cornélien pour l’utilisateur ...

    merci

    Répondre à ce message

  • 3

    A quand une version de test du plugin svp ?
    Y a t’il une roadmap ? (un planning pour parler plus français :-) ) ?

    • Même question...

    • Anthony F.

      Je ne serai pas plus original... ;)

      Cette v2 est très attendue, bon courage pour ce dev !

    • François Daniel Giezendanner

      En effet, la nouvelle version V2 est attendue avec grande impatience.

      Nous utilisons les plugins « Accès restreints par groupes » et « Accès restreints » mais récemment nous avons dû abandonner les plugin « Accès restreints par groupes » pour cause d’extrême ralentissement du site ainsi que nous l’avons mentionné ici :

      Pouvez-vous en tenir compte dans le développement de la version V2 ?

      Voici la teneur du message :

      Ce plugin est génial mais nous avons malheureusement constaté que dans certaines circonstances il se révèle trop lent !

      Dans un premier temps nous avions privilégié le plugin « Accès Restreints par groupes » par rapport au plugin « Accès Restreints ». Malheureusement, dans un site où nous avons défini de nombreux rédacteurs, administrateurs et visiteurs (130 utilisateurs) ainsi que de nombreux espaces restreints (14 espaces), le site est devenu extrêmement lent, au point de devenir inutilisable. Après moult essais, nous avons identifié que le plugin « Accès Restreints par groupes » était la cause de cette lenteur.

      Nous avons alors été obligé de l’abandonner et d’adopter le plugin « Accès Restreints » avec lequel nous n’observons pas de ralentissement du site.

      C’est fort dommage car ce plugin nous plaisait beaucoup !

      Meilleurs messages

      FDG

    Répondre à ce message

  • 7
    Committo, Ergo Sum

    Il me semble qu’une autre dimension n’est pas prise en compte par les deux plugins : l’accès restreint aux pièces jointes. A priori on ne devrait pas pouvoir accéder aux pièces jointes d’une article non publié. Ca se règle par .htacces dans IMG et une redéfinition de generer_url_document, mais on peut aller plus loin. Par exemple restreindre l’accès à certains types de documents mais pas d’autres.

    • Zab de Paris

      Oui, bonne idée cette fusion, et moi aussi, j’aimerais pouvoir télécharger les documents joints aux articles en zones « membres » dans un dossier protégé, mais télécharger des documents dans un autre dossier quand ils sont publics.
      Autrement dit, un téléchargement automatique dans le bon dossier selon l’appartenance de l’article à une zone protégée ou non.

      Et aussi, une protection du dossier qui ne demande pas à l’utilisateur enregistré de saisir à nouveau ses identifiants.

      Est-ce possible ?
      Merci !!!
      Zab

    • Joseph Larmarange

      Pour le moment, il existe le plugin DW2 qui offre un début de restriction d’accès aux documents. Ce plugin est peu connu car non documenté sur Contrib et non développé sur la zone.

      Une des possibilités pourrait consister à ce que les #URL_DOCUMENT pointent sur un script chargé de vérifier les droits et le cas échéant à lire le document en question, tandis qu’un fichier .htaccess interdirait purement et simplement l’accès direct aux documents via leur URL et n’autoriserai la lecture des documents uniquement via le script de vérification des droits.

      Normalement c’est jouable.

    • Joseph Larmarange

      Oups excusez moi. DW2 n’est semble-t-il pas développé sur la zone mais il dispose néanmoins d’une page sur Contrib : http://www.spip-contrib.net/Compteu....

    • Une contrib qui peut -être utile : Protéger le répertoire IMG/

    • Le problème de cette contrib, c’est que soit tous les documents sont protégés, soit aucun ne l’est. En plus, il n’y a pas moyen de faire une protection plus « fine » (ne serait-ce que visiteur/rédacteur/administrateur), mais je pense que ça devrait pouvoir bien s’interfacer avec la future V2.

      Les problèmes de l’accès restreint par DW2 me semblent plus importants. D’une part, il est bogué (il me suffit d’être logué en visiteur pour accéder à des documents pour administrateur, en fermant le formulaire de login) ; d’autre part les documents ne sont pas vraiment protégés. Il y a bien un script qui intercepte #URL_DOCUMENT, mais il fait une simple redirection vers le vrai fichier, qui reste accessible (si on interdit l’accès à IMG/ par un .htaccess, la redirection échoue) et téléchargeable librement une fois qu’on a son adresse.

      Cela dit, prendre le meilleur des deux n’a pas l’air insurmontable pour quelqu’un qui s’y connaît.

    • Des fois il suffit de demander ! Et même si DW2 n’est pas sur la zone, je reste joignable et accessible. si si ! ;-)
      N’ayant pas eu de retour sur la restriction proposé par ce plugin, je ne me suis guère foulé ! Mais ça va changé, je m’y remet d’ici peu ! Et la proposition devrais être un peu moins « inconséquente » !

    • Je suis assez d’accord avec tout le monde il me semble que la gestion des documents joint d’un article devrait faire partie du plugin Acces Restreint.

      Ca me semble logique mais peut être pas si evident que ca à dev je suppose !

    Répondre à ce message

  • 2
    Joseph LARMARANGE

    Il me semble pertinent pour faciliter les discussions à venir de convenir du point de vocabulaire ci-dessous :
    -  zone : ensemble de rubriques.
    -  groupe : ensemble d’auteurs
    -  profil : ensemble de droits, d’autorisation

    Actuellement, Accès restreint définit des zones et donne à des auteurs l’accès à certaines zones. Accès restreint par groupe définit des groupes puis précise les rubriques accessibles à un groupe.

    Les deux cas, il y a trois tables : la table des déifinitions, une table de jointure avec les rubriques et une table de jointure avec les auteurs.

    La définition actuelle des zones est problématique. En effet, une zone est actuellement définie comme un ensemble de branches. Autrement dit, si l’on coche une rubrique, alors toutes les sous-rubriques sont considérées comme appartenant à la zone. Cela interdit pour le moment de réaliser des déifinitions subtiles de zones. Il faudrait pouvoir définir des points d’entrée dans une zone mais également des points de sorties. La définition des zones ne doit pas imposer une arborescence à un site, l’arborescence d’un site devant découler d’une structure logique d’un point de vue sémantique. Au plugin de s’adpater aux différentes arborescences. Pour quelques éléments de réflexions sur le problème de l’héritage des droits et la définition des zones à l’aide de schémas, je renvois au document disponible ici : http://joseph.larmarange.net/Elemen....

    Pour l’heure, il me semble que le concept de zone, en tant qu’ensemble de rubriques, n’est utilisé que par le plugin Accès restreint. La restion reste posée de savoir s’il y aurait un intérêt de ce concept pour d’autres plugins. De la même manière, quels seraient les autres usages de groupes d’auteurs ?

    Si l’on veut disposer à la fois de groupes et d’auteurs, cela induit une multiplication des éléments. Nous aurions alors d’un côté la déclaration de zones avec une table zones et une table de jointure zones_rubriques, une déclaration de groupes d’auteurs, avec une table groupes et une table de jointure groupes_auteurs, et enfin il faudrait réaliser une table de jointure entre les zones et les groupes.

    Sur Spip-Zone, je proposais d’abandonner la notion de zone, ainsi que celle de groupe pour ne retenir que la notion de profils, profils étant entendu comme ensemble de droits. Fondamentalement, cela change techniquement peu de choses au plugin accès restreint tel qu’il existe actuellement. C’est la philosophie sous-jacente qui est modifiée. Dans le cadre de profils, on considère un profil comme un ensemble de droits. Pour un profil donné, je donne des droits d’accès à certaines rubriques dans l’espace privé, et des doits d’accès à certaines rubriques dans l’espace public. Comme il s’agit de droits d’accès, les rubriques concernées pour l’accès public et l’accès privé peuvent différer pour un même profil. Ensuite, les droits définis par un profil sont accordés par un auteur.

    Outre le fait qu’un profil peut accorder des droits différents sur l’espace public et dans l’interface privé, il en résulte que si un droit d’accès est donné à certaines rubriques sur l’espace public, alors ces mêmes rubriques ne sont plus accessibles aux personnes ne disposant pas de droits spécifiques sur elles. Autrement dit, les rubriques accessibles via un profil dépendent des définitions des autres profils. Si l’on prend l’image d’un immeuble, définir des profils consiste à poser des verrous sur des portes. Une fois le verrou posé, les personnes ne disposant pas de la clé ne peuvent plus passer. En même temps, en matière d’héritage des droits, ceux qui appartiennent à ce profil peuvent passer et continuer d’avancer jusqu’à ce qu’ils tombent sur un autre verrou qui aurait été posé par un autre profil. Les points d’entrée d’un profil constitue alors les points de sortie des autres profils.

    En terme de droits, le fait que les rubriques accessibles avec un profil dépendent des autres profils est déjà présent de manière intuitive dans Accès_restreint. En effet, lorsque que l’on définit une zone, on accorde des droits d’accès à cette zone et en même temps on en interdit l’accès aux autres zones. Les zones sont donc en l’état, déjà plus ou moins hybrides car elles sont à la fois un ensemble de rubriques et un ensemble de droits.

    La notion de profil que je développe ici induit un mécanisme assez proche de ce que j’avis proposé il y a quelques mois et peut donc être testé à l’aide du zip disponible ici : http://joseph.larmarange.net/Plugin.... ATTENTION : c’est un zip de dev qui utilise les mêmes tables que Accès Restreint. Ne pas activer Accès restreint en même temps et à n’utiliser que sur un site de test.

    Cette notion de profils n’interdit pas par la suite d’ajouter d’autres définition de droits.
    Comme un profil est un ensemble de droits et non un ensemble d’auteurs, rien n’interdit conceptullement que puisse être développer en parallèle un plugin de reconnaissance d’adresse IP qui attribue les droits définis à un profil à certaines adresses IP.

    Si l’on souhaite retrouver certaines fonctionnalité de accès restreint par groupe, outre le fait que l’on puisse accorder les droits définis dans un profil directement à un auteur, ces droits pourraient également être accordés directement à un statut d’auteur.

    Il me semble qu’il est possible ainsi d’avoir un outil relativement simple au final qui permettrait de faire la meme chose que la définition de zones d’un côté et la définition de groupes de l’autre.

    • La notion de profil est un élément intéressant...
      malheureusement, dans tout système il y aura toujours un utilisateur qui aura besoin d’un acces particulier, faut-il pour autant créer un profil spécifique pour lui ?

      Autre point que je souhaiterais aborder, en plus de la gestion des accès est la gestion des droits... peut être que « autoriser » pourrais être intégré lors du regroupement des plugins...

      Affaire à suivre...

    • Joseph tux

      Est-ce qu’une arborescence hierarchique n’est pas déjà, et simplement, un regroupement de regroupements nommés ?

      Je ne comprend pas bien cette question.

      Ou bien il y a une subtilité qui m’échappe ? ( je n’ai que des rudiments de culture informatique )

      Vision de simple utilisateur

    Répondre à ce message

  • 1

    Je vais parler pour ma paroisse (mais tout le monde fait ça non ?) Pourquoi ne pas donner la possibilité, toute simple, à Accès Restreint V2 de venir prendre ses visiteurs dans une table extérieur à spip ?

    Il faudrait juste pour ce cas indiquer le nom de la table, le nom du champ login et le nom du champ password.

    Je propose cela, car ici je gère déjà plus de 350 users avec une application tiers php/mysql qui change en permanence et cela pourrait éviter d’injecter des users doublons entre les tables.

    Merci de votre oreille attentive ;-)

    • Bonsoir
      J’ai exactement la même demande, c’est a dire de pouvoir utiliser une table externe. Aussi pourquoi ne pas le prévoir sous forme d’option complémentaire : soit l« annuaire » de Spip, soit une table externe. Tiens, soyons fous... les 2 à la fois !
      Car gérer 2 tables annuaires d’utilisateurs en parallèle nécessite trop de temps, et entraîne obligatoirement des erreurs, omissions ou pire des users qu’on oublie de supprimer !
      Alors soyez sympas quoi......

    Répondre à ce message

  • 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

  • 2

    Il me semble important avant que le développement de Accès Restreint V2 ne soit lancé que les points suivants puissent être éclaricis :

    • Quelles sont les règles d’héritage des droits ou dit autrement pourra-t-on enfin définir une zone autrement qu’étant une branche. Cela signifie donc pouvoir préciser pour une zone quels sont ses points d’entrée (comme cela est le cas aujourd’hui) mais également quels sont ses points de sortie (possibilité d’exclure une sous-branche au sein d’une branche).
    • Quel est l’intérêt d’avoir des zones (ensemble de rubriques) défini de manière unitaire quelque soit le contexte ? (je sais vous allez dire que je suis lourd avec ça) ou exprimé autrement ces ensembles de rubriques ont-il un intérêt pour d’autres plugins existants ou à venir ?
    • Dans le même esprit, y a t il un intérêt à avoir des groupes d’auteurs (ensemble d’auteurs) bien défini ? Cela concerne-t-il également d’autres plugins existants ou à venir ?
    • Si les zones (ensembles de rubriques) et les groupes (ensembles d’auteurs) peuvent concerner d’autres plugins, quelle est la meilleure manière de les organiser afin que plusieurs plugins puissent utiliser les mêmes zones / groupes et éviter ainsi d’avoir à démultiplier les tables et les définitions.
    • Si les zones et les groupes n’ont d’intérêt que pour Accès Restreint, est-il vraiment nécessaire d’avoir cette double complexité et une solution plus simple ne serait-elle pas de n’avoir que des profils (ensemble de droits) qui eux ne nécessite ni des définitions unitaires de zones ni des définitions unitaires de rubriques, solution qui peut permettre d’arriver au même résultat avec le même nombre de tables qu’actuellement tout en offrant plus de souplesse.

    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

  • rburton

    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

  • 4
    rburton

    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.

    • Joseph LARMARANGE

      à 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 !

    • rburton

       :-)
      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

  • webzone

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom