Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Comment les permissions sont calculées ?, celle pour les versions 3.x de Moodle est consultable ici : Comment les permissions sont calculées ? et celle pour Moodle 4.x est consultable là : Comment les permissions sont calculées ?.

« Comment les permissions sont calculées ? » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
m (→‎Un exemple : Ancrage corrigé)
Ligne 82 : Ligne 82 :


Il est à remarquer que le rôle ''R1'' a été attribué dans deux contextes distincts. C'est une pratique inhabituelle, vraisemblablement une erreur, mais comme c'est autorisé dans Moodle, nous devons considérer cette possibilité qui pourrait survenir. En réalité, cet exemple a été construit afin d'explorer les cas limites de l'algorithme. Dans la pratique, le calcul des permissions est trivial et la fonction calcule le résultat que le bon sens et une simple analyse suggèrent (pour une discussion plus complète sur ce sujet, voir [[#Une remarque au sujet de l'algorithme|Une remarque au sujet de l'algorithme]] à la fin de cette page.
Il est à remarquer que le rôle ''R1'' a été attribué dans deux contextes distincts. C'est une pratique inhabituelle, vraisemblablement une erreur, mais comme c'est autorisé dans Moodle, nous devons considérer cette possibilité qui pourrait survenir. En réalité, cet exemple a été construit afin d'explorer les cas limites de l'algorithme. Dans la pratique, le calcul des permissions est trivial et la fonction calcule le résultat que le bon sens et une simple analyse suggèrent (pour une discussion plus complète sur ce sujet, voir [[#Une remarque au sujet de l'algorithme|Une remarque au sujet de l'algorithme]] à la fin de cette page.
=== Représentation des données dans un tableau ===
Pour afficher de manière concise les données de permission, nous utilisons un tableau conprenant
* une colonne pour chaque attribution de rôle, triées par ordre croissant de profondeur de l'attribution. Les colonnes sont étiquetées avec les noms des rôles ;   
* une rangée pour chaque niveau de contexte, triées par ordre croissant de profondeur de l'imbrication. Les rangées sont étiquetées avec le niveau du contexte.
Dans l'exemple du test, ''R1'' est attribué dans le contexte Système. On le place donc dans la 1ère colonne. Les rôles ''R2'' et ''R3'' sont attribués dans le deuxième plus haut contexte. Ils sont donc placés dans les deux colonnes suivantes (leur ordre n'importe pas). Les rôles ''R4'' et ''R1'' sont attribués dans le contexte le plus bas. Nous les plaçons donc en dernier (ici encore, leur ordre n'importe pas). Voici donc notre tableau avec les colonnes et les rangées et leurs étiquettes :
        R1  R2  R3  R4  R1
      +------------------------
    0 |
    1 |
    2 |
    3 |
    4 |
Nous ajoutons des lignes verticales pour grouper les attributions de rôle effectuées dans le même contexte.
        R1  R2  R3  R4  R1
      +-----+---------+--------
    0 |    |        |
    1 |    |        |
    2 |    |        |
    3 |    |        |
    4 |    |        |
Nous pouvons maintenant incorporer au tableau les données de permission. Dans la première rangée, nous plaçons les permissions indiquées dans la définition des rôles.
        R1  R2  R3  R4  R1
      +-----+---------+--------
    0 |  A  | N    N  | P    A
    1 |    |        |
    2 |    |        |
    3 |    |        |
    4 |    |        |
Le reste des données provient des dérogations. Nous plaçons la valeur de chaque dérogation dans
* la colonne correspondant au rôle pour lequel la dérogation est effectuée ;
* la rangée correspondant au niveau dans lequel la dérogation est effectuée.
Commençons par ajouter l'une des dérogations :
        R1  R2  R3  R4  R1
      +-----+---------+--------
    0 |  A  | N    N  | P    A
    1 |    |        |
    2 |    |        |
    3 |    | X      |
    4 |    |        |
Le X représente la dérogation du rôle ''R2'' effectuée dans le contexte du cours. Ajoutons maintenant le reste des dérogations :
        R1  R2  R3  R4  R1
      +-----+---------+--------
    0 |  A  | N    N  | P    A
    1 |  N  |        | N    N
    2 |    |        |
    3 |    | X    A  |
    4 |    |        |
Le tableau est maintenant complet. Nous pouvons calculer la permission.


=== L'algorithme ===
=== L'algorithme ===

Version du 27 février 2008 à 20:41

Une des questions posées très fréquemment est : Quelles permissions possède un utilisateur pour un contexte donné ?

Cette page explique la fonction principale de Moodle utilisée pour répondre à cette question. Cette fonction est has_capability(). Elle se trouve dans le fichier lib/accesslib.php. Cette fonction implémente les règles pour calculer la "somme" des permissions de multiples rôles et dérogations. Pour un utilisateur donné, une capacité, et un contexte, la fonction renvoi true (vrai) si l'utilisateur est autorisé à effectuer l'action contrôlée par la capacité dans le contexte donné, et false (faux) sinon.

Cette page est écrite autant pour les non programmeurs que pour les programmeurs. Elle décrit ce que la fonction fait, pas comment. Le comment est compliqué, alors que le quoi est relativement simple !

Remarquez que la fonction n'essaie pas de répondre à la grande question posée dans la première phrase de cette page. Elle répond plutôt à la petite question Un utilisateur peut-il ici faire l'action correspondant à la capacité CAP ? Moodle ne calcule jamais la totalité des permissions d'un utilisateur. Une telle opération serait très coûteuse et n'apporterait pas grand chose, puisque la plupart des permissions ne seraient jamais testées. Moodle calcule donc les permissions à la demande. Moodle ne place pas en cache les permissions calculées, mais les recalcule chaque fois qu'il est nécessaire de les tester. C'est la raison pour laquelle les attributions de rôles et les dérogations prennent effet immédiatement (ce n'était pas le cas dans Moodle 1.7).

Le calcul

La fonction est appelée ainsi :

   has_capability(CAP,CONTEXTE,UTILISATEUR);
  • CAP est la capacité testée (par exemple mod/quiz:attempt)
  • CONTEXTE est le contexte Système ou tout autre contexte imbriqué de façon arbitraire dans le contexte Système. À l'interne, la fonction utilise une notation analogue à celle des chemins d'accès des fichiers Unix pour représenter les contextes (par exemple, /1/3/4/150). De tels détails ne sont pas nécessaires dans cette discussion.
  • UTILISATEUR est l'utilisateur.

La fonction retourne un résultat vrai/faux :

  • true signifie que l'utilisateur est autorisé à effectuer l'action ;
  • false signifie que l'utilisateur n'est pas autorisé à effectuer l'action.

Données utilisées par la fonction

Supposons que l'utilisateur UTILISATEUR soit sur le point de tenter un test (CAP = mod/quiz:attempt) dans le contexte d'un module imbriqué quatre niveaux au-dessous du contexte Système.

     Système
        |
    Catégorie A
        |					      
   Sous-catégorie B
        |
      Cours
        |
      Test  <--- l'utilisateur est ici

Le module Test fera appel à la fonction has_capability() pour déterminer s'il doit permettre à l'utilisateur d'effectuer cette action.

La fonction considère les données de permissions suivantes :

  • les définitions des rôles (situées dans le contexte Système),
  • les attributions de rôles qui ont été effectuées dans n'importe lequel des cinq contextes concernés,
  • les dérogations aux rôles ayant été définies dans n'importe lequel des contextes, sauf le contexte Système (il n'y a pas de dérogation de rôles possible dans le contexte Système).

Il est à remarquer qu'il peut y avoir plusieurs rôles attribués et/ou plusieurs dérogations définies dans un même contexte.

La permission pour l'utilisateur de tenter le test ou non dépend des données ci-dessus, ainsi que de l'emplacement de ces données dans la chaîne des contextes.

La fonction has_capability() considère tous les rôles et toutes les dérogations ayant un impact sur UTILISATEUR dans CONTEXTE, mais elle ignore toutes les capacités autres que CAP. Elle ignore notamment :

  • les rôles qui ne sont pas attribués à l'utilisateur,
  • les capacités autres que celles que nous testons et
  • les permissions qui ne sont pas définies.

Cette simplification nous permet de voir chaque rôle ou chaque dérogation comme une simple permission ayant l'une des valeurs suivantes

   N - Non défini
   A - Autoriser
   P - Empêcher
   X - Interdire

Pour indiquer la permission associée à un rôle, nous utilisons la notation suivante : Si le rôle R1 a la permission P, nous écrivons R1(P).

Un exemple

Dans l'exemple de notre test, nous admettons que UTILISATEUR a quatre rôles : R1, R2, R3 et R4, et que chaque rôle a été attribué ou qu'une dérogation a été définie ainsi :

   0    Système         <---- Définition des permissions R1(A), R2(N), R3(N), R4(P)
           |                  Attribution du rôle R1
           |
   1   Catégorie A      <-------------- Définition des dérogations R1(N) et R4(N)
           |                          
           |                          
   2  Sous-catégorie B  <---- Attribution des rôles R2 et R3
           |
           |
   3     Cours          <-------------- Définition des dérogations R2(X) et R3(A)
           |
           |
   4     Test           <---- Attribution des rôles R4 et R1

Il est à remarquer que le rôle R1 a été attribué dans deux contextes distincts. C'est une pratique inhabituelle, vraisemblablement une erreur, mais comme c'est autorisé dans Moodle, nous devons considérer cette possibilité qui pourrait survenir. En réalité, cet exemple a été construit afin d'explorer les cas limites de l'algorithme. Dans la pratique, le calcul des permissions est trivial et la fonction calcule le résultat que le bon sens et une simple analyse suggèrent (pour une discussion plus complète sur ce sujet, voir Une remarque au sujet de l'algorithme à la fin de cette page.

Représentation des données dans un tableau

Pour afficher de manière concise les données de permission, nous utilisons un tableau conprenant

  • une colonne pour chaque attribution de rôle, triées par ordre croissant de profondeur de l'attribution. Les colonnes sont étiquetées avec les noms des rôles ;
  • une rangée pour chaque niveau de contexte, triées par ordre croissant de profondeur de l'imbrication. Les rangées sont étiquetées avec le niveau du contexte.

Dans l'exemple du test, R1 est attribué dans le contexte Système. On le place donc dans la 1ère colonne. Les rôles R2 et R3 sont attribués dans le deuxième plus haut contexte. Ils sont donc placés dans les deux colonnes suivantes (leur ordre n'importe pas). Les rôles R4 et R1 sont attribués dans le contexte le plus bas. Nous les plaçons donc en dernier (ici encore, leur ordre n'importe pas). Voici donc notre tableau avec les colonnes et les rangées et leurs étiquettes :

        R1   R2   R3   R4   R1
     +------------------------
   0 |
   1 |
   2 |
   3 |
   4 |

Nous ajoutons des lignes verticales pour grouper les attributions de rôle effectuées dans le même contexte.

        R1   R2   R3   R4   R1
     +-----+---------+--------
   0 |     |         |
   1 |     |         |
   2 |     |         |
   3 |     |         |
   4 |     |         |

Nous pouvons maintenant incorporer au tableau les données de permission. Dans la première rangée, nous plaçons les permissions indiquées dans la définition des rôles.

        R1   R2   R3   R4   R1
     +-----+---------+--------
   0 |  A  | N    N  | P    A
   1 |     |         |
   2 |     |         |
   3 |     |         |
   4 |     |         |

Le reste des données provient des dérogations. Nous plaçons la valeur de chaque dérogation dans

  • la colonne correspondant au rôle pour lequel la dérogation est effectuée ;
  • la rangée correspondant au niveau dans lequel la dérogation est effectuée.

Commençons par ajouter l'une des dérogations :

        R1   R2   R3   R4   R1
     +-----+---------+--------
   0 |  A  | N    N  | P    A
   1 |     |         |
   2 |     |         |
   3 |     | X       |
   4 |     |         |

Le X représente la dérogation du rôle R2 effectuée dans le contexte du cours. Ajoutons maintenant le reste des dérogations :

        R1   R2   R3   R4   R1
     +-----+---------+--------
   0 |  A  | N    N  | P    A
   1 |  N  |         | N    N
   2 |     |         |
   3 |     | X    A  |
   4 |     |         |

Le tableau est maintenant complet. Nous pouvons calculer la permission.

L'algorithme

Avant d'effectuer notre "addition," nous vérifions si les données contiennent un X (Interdire) quelque part. Si c'est le cas, nous avons terminé : la permission calculée est alors X. Dans notre exemple :

   P  A  P
         A
   P  A  X
   A     P
      P  A
   --------
      X    <----- permission calculée


S'il n'y a pas de X, l'algorithme d'addition doit être utilisé. Comme il ne s'agit pas d'une véritable addition, l'algorithme

  • commence à la dernière ligne et remonte ligne par ligne,
  • considère la totalité d'une ligne à la fois (au lieu de travailler en colonnes),
  • peut se terminer avant d'atteindre la ligne du haut.

Voici comment fonctionne l'algorithme :

  1. Commencer sur la dernière ligne.
  2. S'il n'y a qu'une seule permission sur la ligne, la permission calculée est la valeur de cette permssion ; STOP.
  3. S'il y a deux ou plus de permissions sur la ligne, les additionner en prenant les valeurs numériques suivantes : A = +1, P = -1.
    • Si la somme est positive, la permission calculée est A ; STOP.
    • Si la somme est négative, la permission calculée est P ; STOP.
    • Si la somme est nulle, le calcul ne permet pas de conclure. Si nous sommes déjà sur la ligne du haut, la permission calculée est P ; STOP. Sinon, passer à la ligne supérieure et aller à l'étape 2.

L'algorithme se termine soit (1) quand un résultat déterminant est obtenu, soit (2) quand la ligne du haut est atteinte sans obtenir de résultat déterminant.

Application de l'algorithme à notre exemple

Reprenons notre exemple initial, en remplaçant le X par un P pour le rendre plus intéressant :

   P  A  P
         A
   P  A  P
   A     P
      P  A
   --------
      ?   

Effectuons maintenant les étapes de l'algorithme.

  • Il y a deux permissions sur la ligne 5.
  • Puisque P + A = 0, le résultat n'est pas déterminant et nous passons donc à la ligne 4.
  • Il y a deux permissions sur la ligne 4.
  • Puisque A + P = 0, le résultat n'est pas déterminant et nous passons donc à la ligne 3.
  • Il y a trois permissions sur la ligne 3.
  • Puisque A + P + P = -1 nous avons un résultat déterminant ! La permission calculée est P.
   P  A  P
         A
   P  A  P
   A     P
      P  A
   --------
      P       <----- permission calculée

Si la permission calculée avait été A, la fonction aurait retourné la valeur true, permettant ainsi à UTILISATEUR d'effectuer l'action.

Cependant, si la permission calculée est P ou X, la fonction ne retourne pas tout de suite false. Elle teste encore si UTILISATEUR a la capacité moodle/site:doanything = A (car cette permission a priorité sur toutes les autres). La fonction effectue ce contrôle en s'auto-appelant :

       résultat final = has_capability(moodle/site:doanything, CONTEXTE, UTILISATEUR);

Une remarque au sujet de l'algorithme

Earlier, we said that the algorithm "calculates the result you would expect." But what do we expect? Intuition tells us that permissions closer to the user should carry more weight than more distant permissions. That's why we set up the table the way we did and why the algorithm walks the table in the order that it does. The last column of the table represents the role assignment(s) closest to the user. The second-to-last column represents the role assignent(s) that are next in terms of distance from the user, and so-on. That's why the algorithm considers the columns from right-to-left. Within a column, the algorithm searches upward in order to give higher weight to overrides that are closer to the user. Once again, this matches our intuition about overrides. If there are no overrides in a column (or the overrides are all Not set), the permission in the role definition is used.

Voir aussi