Difference between revisions of "ACL and Groups/Francais"

From Mumble Wiki
Jump to: navigation, search
Line 20: Line 20:
 
Regardez cet exemple pratique; sur le groupe admin. A chaque fois qu'un joueur cree un canal, il est automatiquement ajouté au groupe des admins. Cela ne lui donne pas automaniquement des privileges, il est juste marque comme membre de ce groupe, cependant l'installation par defaut de Murmur installe une ACL qui donne au groupe admin la bit d'écriture (Tous les accès).
 
Regardez cet exemple pratique; sur le groupe admin. A chaque fois qu'un joueur cree un canal, il est automatiquement ajouté au groupe des admins. Cela ne lui donne pas automaniquement des privileges, il est juste marque comme membre de ce groupe, cependant l'installation par defaut de Murmur installe une ACL qui donne au groupe admin la bit d'écriture (Tous les accès).
  
In a structure like this:
+
Dans une structure comme celle-ci:
  
 
     * Root
 
     * Root
Line 39: Line 39:
  
 
Le Canal D héritera la liste de C, à moins que C ne marque aussi l'administration comme non génétique.  
 
Le Canal D héritera la liste de C, à moins que C ne marque aussi l'administration comme non génétique.  
 +
 +
Les ACL
 +
 +
ACL (Access Control Lists) sont attachée a un canal spécifique. Un canal peut spécifier si il veut hériter l'ACL sur le parent, mais il ne peut pas spécifier lequel; Il est tout ou rien l'affaire.
 +
Les ACL sont évaluées dans l'ordre, de haut en bas le long de la liste des canaux.
 +
 +
Pour chaque entrée, "either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a !, it's membership is inverted, and if it begins with a ~, it is evaluated in the context of the channel the ACL is defined on (and not the active channel).
 +
 +
    all
 +
 +
Everyone
 +
 +
    auth
 +
 +
All authenticated users
 +
 +
    in
 +
 +
All users inside current channel
 +
 +
    out
 +
 +
All users outside current channel
 +
 +
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:
 +
 +
    * @all deny speak
 +
    * @all allow speak
 +
 +
Then everyone will be allowed to speak. On the other hand
 +
 +
    * @all allow speak
 +
    * @all deny speak
 +
 +
Will deny speak from everyone.
 +
 +
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels and allow inheritance in the subchannels.
  
 
"Je continue plus tard car j'ai fait ca rapidement ;-)  Gecko64"
 
"Je continue plus tard car j'ai fait ca rapidement ;-)  Gecko64"

Revision as of 22:21, 4 September 2007

Tutorial

Vous pouvez trouver un tutorial illustré et un guide rapide sur Comment administrer les groupes et les permissions: ACL Tutorial

Les Groupes

Les groupes sont liés à un canal spécifique, mais vous pouvez aussi les faire hériter a des sous canaux. Les groupes sont des façons commodes d'administrer des canaux, de definir les ACLs tout en haut de l'arborescence "that should have similar privilege structure, and just change the group memberships on subchannels."


Pour chaque canal, un groupe a 3 parties specifiques qui sont:

- La liste des joueurs pour ajouter au groupe. - La liste des joueurs héritée du meme groupe sur le canal parent. - Et pour terminer, la liste des joueurs pour enlever du groupe.

Un groupe héritera seulement des joueurs du canal parent si seulement l'heritage est activé et que le groupe a été marque comme pouvent hériter du parent. La plupart du temps, vous "want both of these to be set."

Exemple

Regardez cet exemple pratique; sur le groupe admin. A chaque fois qu'un joueur cree un canal, il est automatiquement ajouté au groupe des admins. Cela ne lui donne pas automaniquement des privileges, il est juste marque comme membre de ce groupe, cependant l'installation par defaut de Murmur installe une ACL qui donne au groupe admin la bit d'écriture (Tous les accès).

Dans une structure comme celle-ci:

   * Root
         o A
               + B 
         o C
               + D 


En Root, le joueur "Big Boss" est tout seul dans le groupe administrateur. Dans le canal A "BossA" est dans la Addlist, et "BossB" est dans le meme canal B. Depuis que le groupe admin est herité et génétique, Un joueur qui est un membre à n'importe quel parent du canal actuel est aussi un membre dans le canal actuel. Donc la liste totale des membre du canal B est "Big Boss, BossA, BossB".

La commodité de ce systeme est que si plus tard on ajoute "Super Boss" en tant que admin dans le root, il sera automatiquement dans le groupe administrateur de chaque canaux en dessous.

Disons maintenant que le joueur "BossC" est dans la Add list dans le canal C, mais ici l'administration est marquée comme pas héritent. Cela signifie que "Big Boss" n'est pas dans la liste d'administration et on ne verra pas de changements pour l'administration dans la Racine ici.

Le Canal D héritera la liste de C, à moins que C ne marque aussi l'administration comme non génétique.

Les ACL

ACL (Access Control Lists) sont attachée a un canal spécifique. Un canal peut spécifier si il veut hériter l'ACL sur le parent, mais il ne peut pas spécifier lequel; Il est tout ou rien l'affaire. Les ACL sont évaluées dans l'ordre, de haut en bas le long de la liste des canaux.

Pour chaque entrée, "either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a !, it's membership is inverted, and if it begins with a ~, it is evaluated in the context of the channel the ACL is defined on (and not the active channel).

   all 

Everyone

   auth 

All authenticated users

   in 

All users inside current channel

   out 

All users outside current channel

For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:

   * @all deny speak
   * @all allow speak 

Then everyone will be allowed to speak. On the other hand

   * @all allow speak
   * @all deny speak 

Will deny speak from everyone.

Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels and allow inheritance in the subchannels.

"Je continue plus tard car j'ai fait ca rapidement ;-) Gecko64"