De la formation à la contribution

Le module Back-office Access Restriction est dédié aux environnements de production sur lesquels on souhaite interdire définitivement l'accès à certaines page d'administration. Ce module est né de notre expérience en formation. Nombreux sont les participants qui ont trouvé l'approche très intéressante et qui ont donc poussé pour qu'il soit disponible de tous sur drupal.org.

Naissance du projet

Lors des formations Drupal 8 Développeur Back-End proposées par Trained People, on découvre l'Event Dispatcher qui remplace petit à petit les hooks historiques de Drupal. Cela permet de réagir lorsque certains événements se produisent, par exemple lorsque le système de routing est reconstruit.

D'autres part de nombreux participants à nos formations s'interrogeaient sur l'utilité de définir un accès refusé (403) sur certaines routes. C'est là que l'idée de faire un petit module utilitaire qui permet de bloquer en partie le back-office est née !

Au final ce module fait partie intégrante de la formation et est maintenant disponible pour tous. On est passé ainsi de la formation à la contribution.

Quel est le problème ?

Sur de nombreux sites Drupal en production, l'utilisateur 1 est connecté quotidiennement. Ceci a pour conséquence que l'on peut réaliser n'importe quelle tâche d'administration et de paramétrage du coeur du système et/ou des modules. Afin d'éviter cela le module Back-office Access Restriction permet de lister les différentes pages (routes) que l'on souhaite interdire définitivement.

Comment cela marche ?

Afin d'interdire certaines routes aux utilisateurs, on créer un service taggué event_subscriber qui étend la classe RouteSubscriberBase(). Ainsi on intercepte la liste de toutes les routes du système et on a alors la possibilité de modifier n'importe laquelle d'entre elles. Il suffit alors de leurs appliquer un requirements à 'FALSE'.

foreach ($this->routes as $route_name) { $route = $collection->get($route_name); $route->setRequirements(['_access' => 'FALSE']); }

La liste des routes est passée en paramètre du service, ce qui permet de pouvoir créer une liste "maison" sans avoir à modifier le code du module (personne ne modifie le code contrib, hein ?). On peut par exemple avoir un fichier /sites/default/services.yml tel que :

parameters: backoffice_access_restriction.routes: - system.modules_list - system.modules_uninstall - user.admin_permissions

Ici les pages de listing des modules, de dés-installation des modules et de configuration des permissions renvoient une réponse 403 (Accès Refusé) à tous les utilisateurs.

Ce module n'a aucune utilité en dehors d'un environnement de production. Il ne devrait donc pas être installé sur les autres (développement, QA, pré-production...).

N'hésitez donc pas à installer ce module, d'autant plus qu'il n'a aucune incidence sur les performances du site.