MarcWiki

Le wiki de Marc Meurrens

Acls

Resp. Inconnu marc Mise à jour 25 Mai 2009 à 20h24 par marc

ACL

Un acronyme pour Acces Control Level.

Les ACLs sont définies, pratiquement, dans plusieurs fichiers de configuration, de manières qui peuvent paraître contradictoires : cette contradiction n'est qu'apparente, les nouvelles valeurs remplaçant les anciennes; nouvelles signifiant particulière par rapport à général, ou propre à une installation par rapport à par défaut, ou encore action qualifiée (à comprendre plus bas) par rapport à action générale.

Les personnes concernées

On distingue, par ordre décroissant d'importance :

• l'administrateur ou root, noté dans les définitions par le caractère ! (point d'exclamation); dans cette version du logiciel, il n'existe qu'un seul administrateur; mais, voir ci-dessous, on peut aussi créer des droits particuliers pour des utilisateurs particuliers
• un utilisateur particulier untel, ce qui sera noté par untel; bien entendu, cet utilisateur aura du se connecter (fournir son password); voir l'exemple plus bas.
• tout utilisateur connecté (donc qui a fourni son password), noté par + (plus); attention : si un visiteur quelconque a le droit de s'inscrire lui-même, celà signifie que tout le monde peut virtuellement accéder au droits de l'utilisateur connecté (ce n'est pas du tout un non sens : on peut choisir de ne laisser faire des modifications qu'à ceux qui ont, plus ou moins, annoncé leur identité).
• tout visiteur (donc, le monde entier), noté par * (astérisque)

groupe d'utilisateurs

Dans cette version du logiciel, il n'existe pas de groupes d'utilisateurs (par exemple : les 3 utilisateurs jean, pierre et jacques regroupés sous le nom de cuisiniers)

Mais rien n'empêche d'écrire :

TODO : vérifier si on peut faire :

• "default_agenda:add_acl" => "jean,pierre,jacques",

ou si il faut faire

• "default_agenda:add_acl" => "jean",
• "default_agenda:add_acl" => "pierre",
• "default_agenda:add_acl" => "jacques",

??? pas très important !

exemple

Nous pourrons donc, par exemple, offrir à l'utilisateur connecté nathan le droit de modifier l'agenda en mentionnant quelque part (à voir plus bas) quelque chose qui ressemble à :

• "default_agenda:add_acl" => "nathan",

Actions et utilisateurs

Dans l'exemple ci-dessus, default rappelle que cette définition n'est jamais qu'une valeur par défaut susceptible d'être encore modifiée selon des règles encore plus particulières (page par page).

agenda est le nom d'une action; normalement, ce devrait être lire l'agenda.

:add qualifie cette action : il s'agit ici d'ajouter des informations dans l'agenda.

nathan est l'utilisateur qui reçoit l'autorisation; nous aurions pu écrire "+" pour indiquer tout utilisateur connecté (on dit parfois utilisateur loggué) c'est à dire ayant introduit son login et son password (ou, si vous préferez, son identifiant et son mot de passe).

Actions

Une liste des principales actions concernées par les ACLs sera bientôt disponible ici.

Les ACLs dans la configuration par défaut

Dans le fichier kernel/config/wakka.config.default.php, rédigé en PHP mais compréhensible (?) pour un profane en informatique, on trouve les définitions suivantes :

• "default_root_acl" => "!", /* Permissions par défaut pour le root */
• "default_action_acl" => "*", /* Permission par défaut des actions */

• /* exceptions pour des actions particulières : */
• "default_read_acl" => "*", /* lire les pages */
• "default_comments_acl" => "*", /* lire les commentaires */
• "default_comments:add_acl" => "+", /* ajouter un commentaire (donc, dans ce cas + signifie qu'on réserve ce droit aux seuls utilisateurs connectés) ; notez qu'ici l'action comments est qualifiée par add */

• /* une série de droits offerts par défaut à tous : en gros, on complète l'accès en lecture aux pages et fichiers */
• "default_file_acl" => "*",
• "default_header_acl" => "*",
• "default_install_acl" => "*",
• "default_footer_acl" => "*",
• "default_config_acl" => "*",

• /* quelques actions plus spéciales sont réservées : */
• "default_login:mod_acl" => "!", /* ??? */
• "default_account_acl" => "*", /* ??? */
• "default_mail_acl" => "+",
• "default_edit:acls_acl" => "+",
• "default_edit:date_acl" => "+",
• "default_edit:move_acl" => "!",

Les valeurs ci-dessus vont toutefois être modifiées dès l'installation.

A l'installation

Il est possible de définir les ACLs (pluriel de ACL) qui seront appliqués par défaut.
Pour celà il faut choisir un profil (ou AccesModel) parmi les suivants :
- OpenWiki : tout le monde peut tout faire
- PrivateWorkingGroup : les initiés et eux seuls peuvent tout faire
- PublicationCommunity : les rédacteurs seuls peuvent écrire mais tout le monde peut lire
- RootOnly : le bloc-note en ligne d'une seule personne, l'administrateur ou root.

En fait, dans la version 9.3-beta, il semble (?) y avoir un bug si nous choisissons autre chose que OpenWiki.

Cela n'est pas grave car nous pouvons modifier ultérieurement la configuration (voir plus bas).

Les ACLs dans les 4 profils

OpenWiki

Dans le profil OpenWiki, les valeurs suivantes sont différentes de celles ci-dessus (autrement dit, sont modifiées) :


On voit que tout le monde (donc "*") peut tout faire, sauf monter des fichiers (un peu dangereux si on laisse faire les pirates) ce qui est réservé aux utilisateurs connectés (donc "*") et gérer les droits ce qui est réservé à l'administrateur (donc "!").

PrivateWorkingGroup

Dans le profil PrivateWorkingGroup, toutes les actions sont réservées aux seuls utilisateurs connectés :


Puisque cette définition intervient après, elle annule les dispositions relativement généreuses (droits en lecture) de la configuration par défaut.

PublicationCommunity

Dans la PublicationCommunity" on est plus libéral : lire les pages, les commentaires et accéder aux fichiers est désormais public, ce qui note par "*" :


Ecrire les contenus et coopter ses membres (???) est toutefois un droit exclusif de la communauté des utilisateurs connectés.

RootOnly

Enfin, sans surprise, dans le cas du RootOnly, l'administrateur (le root) se réserve toutes les actions :


ce qui annule, à nouveau, la relative générosité de la configuration par défaut.

Nos propres configurations

au départ

Il ne faut surtout pas aller modifier, comme une brute épaisse, le fichier de configuration qui se trouve dans le kernel (noyau permanent du logiciel).

Lors de l'installation, le fichier local/config/wakka.config.php a été créé; c'est là, en respectant prudemment la syntaxe du PHP, qu'il faut apporter les adaptations.

Attention : ce fichier contient aussi des paramètres relatifs à d'autres choses que les ACLs.

Puisque nous créons par défaut un OpenWiki, nous trouvons sans surprise dans ce fichier les valeurs suivantes :


que nous allons donc modifier comme indiqué ci-dessous pour deux cas particuliers : adelin, un wiki à l'usage d'un groupe restreint, et marc, un bloc-note personnel mais public.

adelin (ou david)

Dans la configuration adelin, nous remplaçons par ceci :


c'est à dire tous les droits à toute la communauté des utilisateurs connectés, sauf l'envoi de mails qui est autorisé pour le monde entier (pour permettre à quelqu'un qui a oublié son password ou qui frappe à la porte de contacter les responsables) et sauf la gestion suprême des droits réservé à l'administrateur.

marc

• "default_edit_acl" => "+", */ seuls les membres peuvent écrire */
• "default_read_acl" => "*", /* les visiteurs peuvent lire */
• "default_comments_acl" => "*", /* les visiteurs peuvent lire les commentaires */
• "default_files_acl" => "*", /* les visiteurs peuvent voir les fichiers */
• "default_files:add_acl" => "+", /* seuls les membres peuvent en ajouter */
• "default_mail_acl" => "*", /* les visiteurs peuvent envoyer des mails aux membres */
• "default_comments:add_acl" => "*", /* les visiteurs peuvent ajouter des commentaires */
• "default_me:add" => "+", /* empecher un visiteur de se créer un compte, les membres peuvent ajouter de nouveaux membres */
• "default_agenda_acl" => "+", /* gérer l'agenda */
• "default_agenda:add_acl" => "+", /* gérer l'agenda */
• "default_file_acl" => "*",
• "default_header_acl" => "*",
• "default_install_acl" => "*",
• "default_footer_acl" => "*",
• "default_config_acl" => "*",
• /* ??? "default_acls_acl" => "!", /* ??? */

ACLs page par page

Dans certains cas, il peut être utile de modifier les droits d'accès page par page.

Ce qu'il est possible de faire et comment le faire est décrit ici

Dans quels cas ?

Exemple A

Dans un wiki que je rends lisible au monde entier (la configuration marc ci-dessus), je peux décider que certaines pages (familliales, en construction, privées, etc) doivent être d'un accès plus limité.

Exemple B

Dans un wiki complètement fermé (la configuration adelin ci-dessus), on peut décider néanmoins que la page d'accueil soit publique pour contenir une explication, une possibilité d'inscription, etc.

Exemple C

On peut décider que des pages en cours d'élaboration soient publiquement modifiables et commentables; mais que par contre des citations originales, des extraits d'autres publications et les textes dans une version définitive ne puissent plus être modifiés mais puissent encore être commentés.

Exemple D

On peut vouloir se réserver temporairement les droits d'éditer une page sur la quelle on est occupé à travailler pour éviter que d'autres ne bousillent malencontreusement le contenu par une intervention simultanée.

A COMPARER

La gestion des droits d'accès des visiteurs, utilisateurs, rédacteurs, administrateurs, etc au site, aux pages, aux fonctionnalités est réglée par ce qu'on appelle, dans le jargon des wikis, des ACLs.

ACL

Un acronyme pour Acces Control Level.

Les ACLs sont définies, pratiquement, dans plusieurs fichiers de configuration, de manières qui peuvent paraître contradictoires : cette contradiction n'est qu'apparente, les nouvelles valeurs remplaçant les anciennes; nouvelles signifiant particulière par rapport à général, ou propre à une installation par rapport à par défaut, ou encore action qualifiée (à comprendre plus bas) par rapport à action générale.

Les personnes concernées

On distingue, par ordre décroissant d'importance :

• l'administrateur ou root, noté dans les définitions par le caractère ! (point d'exclamation); dans cette version du logiciel, il n'existe qu'un seul administrateur; mais, voir ci-dessous, on peut aussi créer des droits particuliers pour des utilisateurs particuliers
• un utilisateur particulier untel, ce qui sera noté par untel; bien entendu, cet utilisateur aura du se connecter (fournir son password); voir l'exemple plus bas.
• tout utilisateur connecté (donc qui a fourni son password), noté par + (plus); attention : si un visiteur quelconque a le droit de s'inscrire lui-même, celà signifie que tout le monde peut virtuellement accéder aux droits de l'utilisateur connecté (ce n'est pas du tout un non sens : on peut choisir de ne laisser faire des modifications qu'à ceux qui ont, plus ou moins, annoncé leur identité).
• tout visiteur (donc, le monde entier), noté par * (astérisque)

groupe d'utilisateurs

Dans cette version du logiciel, il n'existe pas de groupes d'utilisateurs (par exemple : les 3 utilisateurs jean, pierre et jacques regroupés sous le nom de cuisiniers)

Mais rien n'empêche d'écrire :

TODO : vérifier si on peut faire :

• "default_agenda:add_acl" => "jean,pierre,jacques",

ou si il faut faire

• "default_agenda:add_acl" => "jean",
• "default_agenda:add_acl" => "pierre",
• "default_agenda:add_acl" => "jacques",

??? pas très important !

exemple

Nous pourrons donc, par exemple, offrir à l'utilisateur connecté nathan le droit de modifier l'agenda en mentionnant quelque part (à voir plus bas) quelque chose qui ressemble à :

• "default_agenda:add_acl" => "nathan",

Actions et utilisateurs

Dans l'exemple ci-dessus, default rappelle que cette définition n'est jamais qu'une valeur par défaut susceptible d'être encore modifiée selon des règles encore plus particulières (page par page).

agenda est le nom d'une action; normalement, ce devrait être lire l'agenda.

:add qualifie cette action : il s'agit ici d'ajouter des informations dans l'agenda.

nathan est l'utilisateur qui reçoit l'autorisation; nous aurions pu écrire "+" pour indiquer tout utilisateur connecté (on dit parfois utilisateur loggué) c'est à dire ayant introduit son login et son password (ou, si vous préferez, son identifiant et son mot de passe).

Fonctionnnalités contrôlables

Une liste des principales fonctionnalités concernées par les ACLs sera bientôt disponible ici.

Les ACLs dans la configuration par défaut

Dans le fichier kernel/config/wakka.config.default.php, rédigé en PHP mais compréhensible (?) pour un profane en informatique, on trouve les définitions suivantes :





Les valeurs ci-dessus vont toutefois être modifiées dès l'installation.

A l'installation

Il est possible de définir les ACLs (pluriel de ACL) qui seront appliqués par défaut.
Pour celà il faut choisir un profil (ou AccesModel) parmi les suivants :
- OpenWiki : tout le monde peut tout faire
- PrivateWorkingGroup : les initiés et eux seuls peuvent tout faire
- PublicationCommunity : les rédacteurs seuls peuvent écrire mais tout le monde peut lire
- RootOnly : le bloc-note en ligne d'une seule personne, l'administrateur ou root.

En fait, dans la version 9.3-beta, il semble (?) y avoir un bug si nous choisissons autre chose que OpenWiki.

Cela n'est pas grave car nous pouvons modifier ultérieurement la configuration (voir plus bas).

D'autre part, certains profils, très sévères (comme notre profil pour "Site de collaboration documentaire pour groupe de travail fermé"), ne pourraient être définis dès l'installation car il serait alors impossible, même à l'administrateur, de s'y introduire.

Les ACLs dans les 4 profils

OpenWiki

Dans le profil "OpenWiki", les valeurs suivantes sont différentes de celles ci-dessus (autrement dit, sont modifiées) :


On voit que tout le monde (donc "*") peut tout faire, sauf monter des fichiers (un peu dangereux si on laisse faire les pirates) ce qui est réservé aux utilisateurs connectés (donc "*") et gérer les droits ce qui est réservé à l'administrateur (donc "!").

PrivateWorkingGroup

Dans le profil "PrivateWorkingGroup", toutes les actions sont réservées aux seuls utilisateurs connectés :


Puisque cette définition intervient après, elle annule les dispositions relativement généreuses (droits en lecture) de la configuration par défaut.

PublicationCommunity

Dans la "PublicationCommunity"" on est plus libéral : lire les pages, les commentaires et accéder aux fichiers est désormais public, ce qui note par "*" :


Ecrire les contenus et coopter ses membres (???) est toutefois un droit exclusif de la communauté des utilisateurs connectés.

RootOnly

Enfin, sans surprise, dans le cas du "RootOnly", l'administrateur (le root) se réserve toutes les actions :


ce qui annule, à nouveau, la relative générosité de la configuration par défaut.

Nos propres configurations

au départ

Il ne faut surtout pas aller modifier, comme une brute épaisse, le fichier de configuration qui se trouve dans le kernel (noyau permanent du logiciel).

Lors de l'installation, le fichier local/config/wakka.config.php a été créé; c'est là, en respectant prudemment la syntaxe du PHP, qu'il faut apporter les adaptations.

Attention : ce fichier contient aussi des paramètres relatifs à d'autres choses que les ACLs.

Puisque nous créons par défaut un "OpenWiki", nous trouvons sans surprise dans ce fichier les valeurs suivantes :


que nous allons donc modifier comme indiqué ci-dessous pour deux cas particuliers : "groupe de travail fermé" et bloc-note ouvert.

groupe de travail fermé

Dans cette configuration, nous remplaçons par ceci :

/* les 2 valeurs suivantes font un peu double emploi, car normalement elles devraient toujours avoir les mêmes valeurs */
"default_register_acl" => "+", /* pas d'inscription directe possible par le public : l'invite ne doit pas apparaître */
"default_me:add" => "+", /* les membres peuvent ajouter de nouveaux membres */

"default_edit_acl" => "+", /* modifier page */
"default_read_acl" => "+", /* lire page ; avant de jouer avec ça : vérifier que 'template' est public ! */
"default_comments_acl" => "+", /* lire commentaires */
"default_comments:add_acl" => "+", /* ajouter commentaires */
"default_agenda_acl" => "+", /* lire agenda */
"default_agenda:add_acl" => "+", /* ajouter événement */

"default_mail_acl" => "*", /* envoyer un mail : PUBLIC ! */

"default_files_acl" => "+", /* gérer les fichiers...*/
"default_pages_acl" => "+", /* ... et les pages d'un rédacteur */

"default_log_acl" => "+", /* historique */
/* "default_user_acl" => "+", */
/* la description des rédacteurs (y compris ceux des pages publiques) ne peut être connue du public ;
toutefois ceci provoque un message malvenu ;
nous résolvons le problème autrement */

"default_acls_acl" => "!", /* ??? */

"default_file_acl" => "+", /* */
"default_header_acl" => "+", /* */
"default_install_acl" => "+", /* */
"default_footer_acl" => "+", /* */

"default_config_acl" => "*", /* */


c'est à dire tous les droits à toute la communauté des utilisateurs connectés, sauf l'envoi de mails qui est autorisé pour le monde entier (pour permettre à quelqu'un qui a oublié son password ou qui frappe à la porte de contacter les responsables).

Trucs et ficelles :

• Ne monter cette config que alors qu'on est connecté comme root (sinon on ne pourra plus entrer dans le site).
• S'empresser de déroger aux règles strictes en rendant publique au minimum la page d'accueil et (là est le truc!) la page 'template'.

bloc-note public

ACLs page par page

Dans certains cas, il peut être utile de modifier les droits d'accès page par page.

Ce qu'il est possible de faire et comment le faire est décrit ici

Dans quels cas ?

Exemple A

Dans un wiki que je rends lisible au monde entier (la configuration bloc-note public ci-dessus), je peux décider que certaines pages (familliales, en construction, privées, etc) doivent être d'un accès plus limité.

Exemple B

Dans un wiki complètement fermé (la configuration groupe de travail fermé ci-dessus), on peut décider néanmoins que la page d'accueil soit publique pour contenir une explication, une possibilité d'inscription, etc.

Exemple C

On peut décider que des pages en cours d'élaboration soient publiquement modifiables et commentables; mais que par contre des citations originales, des extraits d'autres publications et les textes dans une version définitive ne puissent plus être modifiés mais puissent encore être commentés.

Exemple D

On peut vouloir se réserver temporairement les droits d'éditer une page sur la quelle on est occupé à travailler pour éviter que d'autres ne bousillent malencontreusement le contenu par une intervention simultanée.