Vous êtes ici

Créer et utiliser des permissions statiques

Vous avez 30 secondes ?
S'abonner au flux d'actualités
Rubrique: 
Technique
Difficultée: 
Facile
Permissions statiques :
Par opposition à une permissioninfo-icon dynamique, une permissioninfo-icon statique est une permissioninfo-icon dont le nombre et la nature sont connus à tout moment. Par exemple administrer le module X constitue une permissioninfo-icon statique : il n'y en a qu'une et elle administre un module défini. Son nombre et sa nature ne varient ni d'un site à l'autre, ni au cours de la vie du site.
 
Dans ce tutoriel, nous nous intéresserons aux permissions simples : les permissions statiques. Prérequis : le module TutoPermissions.
Pour découvrir la déclaration et l'utilisation des permissions dynamiques, lisez le tutoriel associé (à venir) !

Déclarer de nouvelles permissions statiques

La déclaration de nouvelles permissions statiques s'effectue via un fichier YAML qui, par convention, doit avoir pour nom : $module.permissions.yml
 
En pratique, en prenant le module indiqué dans les prérequis, nous allons ajouter un fichier nommé tutopermissions.permissions.yml, puisque tutopermissions est le nom machine de notre module.
Contenu du fichier tutopermissions.permissions.yml :
# Permissioninfo-icon for admin page
access adminpage:
  title: Accéder à la page d'administration
  description: Autoriser l'accès à la page d'administration de TutoPermissions.
  restrict access: TRUE
 
# Permissioninfo-icon for result page
access resultpage:
  title: Accéder à la page de résultat
  description: Autoriser l'accès à la page de résultat de TutoPermissions.
La syntaxe est la suivante : nous déclarons une liste d'éléments étant chacun l'identifiant d'une permissioninfo-icon. Ici, nous en déclarons donc deux :"access adminpage" et "access resultpage". La syntaxe est la suivante :
  • une clef unique pour votre permissioninfo-icon. Celle-ci doit être en minuscule, avec ou sans espaces et sans caractères spéciaux.
    • title (obligatoire) : définit le titre de la permissioninfo-icon. Ce titre sera affiché sur la page des droits d'accès /admin/people/permissions.
    • description (obligatoire) : définit la description de la permissioninfo-icon. Cette permissioninfo-icon sera affichée sur la page des droits d'accès.
    • restrict access (facultatif) : il arrive que votre module permette certaines choses potentiellement dangereuses si utilisées par de mauvaises personnes. Par exemple, si votre module permet de supprimer toute la base de données ! Si indiqué à TRUE, ce champ optionnel ajoute l'affichage d'un message d'avertissement concernant la permissioninfo-icon sur la page de gestion des droits.
    • warning (facultatif) : définit un message personnalisé pour l'avertissement associé à restrict access. Il est recommandé de ne pas utiliser cette propriété afin d'utiliser le message d'avertissement par défaut de Drupal, pour garder une homogénéité des messages d'alertes au sein du site.
Internationalisation des permissions :
Le titre et la description sont automatiquement internationalisables ! En revanche la clef ne l'est pas. Mais celle-ci n'est jamais affichée : c'est simplement une clef d'identification.
 
Vous devriez désormais voir ces deux permissions apparaître pour votre module, sur la page de gestion des droits /admin/people/permissions.
 
Nos deux permissions apparaissent sur la page de gestion des droits. La permissioninfo-icon de la page admin est affichée avec un message d'avertissement.

Utilisation des permissions

Il y a deux moyens pour utiliser nos permissions :
  • au niveau du routage : en appliquant notre permissioninfo-icon à la déclaration de la route d'une page, un utilisateur non autorisé recevra une erreur 403.
  • au sein de notre code : utilisé par exemple pour moduler le résultat d'une page, en fonction du niveau de permissioninfo-icon de l'utilisateur y accédant.

Permissioninfo-icon d'accès à une page

La restriction de l'accès d'un utilisateur à une page s'effectue par la déclaration de la permissioninfo-icon comme critère du routage vers la page. En d'autre terme, c'est en déclarant votre routage dans $module.routing.yml que vous définirez votre permissioninfo-icon comme prérequis à l'accès vers la page. Nous avons déjà vu comment faire cela dans des tutoriaux précédents. Pour tester en pratique, remplacez dans le fichier tutopermissions.routing.yml :
  requirements:
    _permission: 'access content'
par ceci pour la page admin
  requirements:
    _permission: 'access adminpage'
par ceci pour la page résultat
  requirements:
    _permission: 'access resultpage'
Les routes sont mises en cache. Pour prendre en compte cette modification, vous devrez vider le cache ici : /admin/config/development/performance.
 
Si vous utilisez les mêmes permissions que dans l'image ci-dessus, en vous rendant en tant qu'utilisateur anonyme sur la page /admin/config/adminpage, vous devriez désormais voir le classique message : Accès refusé : Vous n'êtes pas autorisé(e) à accéder à cette page suite à une erreur HTTP 403.

Vérifier les permissions d'un utilisateur

Nous avons vu que la seconde possibilité est d'adapter le comportement de votre code en fonction du degré de permissioninfo-icon d'un utilisateur. Pour cela, il suffit d'utiliser la méthode hasPermission() d'un objet utilisateur. L'usage de cette méthode s'effectue comme suit :
// Récupère l'utilisateur courant.
$account = \Drupal::currentUser();
// TRUE si l'utilisateur possède la permissioninfo-icon "access adminpage", FALSE sinon.
$access = $account->hasPermission('access adminpage');
ou encore :
// Importe l'entité User et permet l'usage direct du namespace User.
use \Drupal\user\Entity\User;                            
// Récupère l'entité utilisateur dont l'ID vaut 3.
$account = User::load(3);
// TRUE si le user 3 possède la permissioninfo-icon "access adminpage", FALSE sinon.
$access = $account->hasPermission('access adminpage');
Voyons un cas pratique : remplaçons le code de la fonction resultpage() de la classe src/Controller/TutoPermissionsController.php par le code suivant :
/**
 * Return the 'result' page.
 *
 * @return array A render array containing our 'result' page content.
 */

public function resultpage() {
  $user = \Drupal::currentUser();

  $output = array();
  $output['welcome'] = array(
    '#markup' => $this->t("Bienvenue sur notre fausse page de résultat.")
  );

  if ($user->hasPermission('access adminpage')) {
    $output['admin'] = array(
      '#type' => 'container'
    );
    $output['admin']['infos'] = array(
      '#markup' => $this->t("Quelques infos spécifiques pour l'administration.")
    );
  }

  if ($user->hasPermission('access resultpage')) {
    $output['result'] = array(
      '#type' => 'container'
    );
    $output['result']['infos'] = array(
      '#markup' => $this->t("Quelques résultats...")
    );
  }

  return $output;
}

Désormais, en vous connectant à la page /resultpage avec des utilisateurs de différents rôles, vous devriez avoir un visuel différent dépendant de votre niveau de permissioninfo-icon !
 
Vue pour un utilisateur anonyme.
 
Vue pour un utilisateur administrateur.
 
Le super admin, aussi appelé parfois user #1 (ou user/1) voit tout ! Les permissions ne s'appliquent pas à cet utilisateur au statut particulier. Ne vous méprenez pas lors de vos tests !
 
En résumé...
 
L'ajout de permissions à votre module permet d'ajuster son comportement aux différents rôles du site. La déclaration de nouvelles permissions s'effectue par l'usage d'un fichier $module.permissions.yml décrivant les permissions.
  • Les permissions peuvent être utilisées pour restreindre l'accès à vos pages, en les incluant comme requirements dans la déclaration de vos routes ;
  • Les permissions peuvent être testées au sein de votre code par la méthode :

    $account->hasPermission('clef de la permissioninfo-icon');

Le créateur du site, dit user #1, n'est pas soumis aux permissions : il peut littéralement tout faire !
Fichier(s) joint(s): 
Notation: 
Average: 5 (1 vote)
Vous avez aimé: