Il existe beaucoup de fonctionnalités peu connues dans TYPO3, les « custom permission » en font partie.
Cette fonctionnalité permet d’attribuer des droits particuliers à un utilisateur BackOffice.
A) Présentation
Dans le cas d’un développement backend spécifique, il peut être nécessaire d’avoir des droits spécifiques.
Si on prend comme exemple un module de gestion de newsletters et d’inscriptions, il y avoir des droits spécifiques comme :
- permettre l’accès aux statistiques des newsletters
- permettre l’accès au module de configuration
- etc….
Cela regroupe en fait l’ensemble des fonctionnalités qui peuvent être développées spécifiquement pour ce module et qui pourraient être soumises à une restriction d’accès.
Chaque utilisateur Backend héritant d’un ou plusieurs groupes, on pourrait se baser sur l’UID de ces groupes pour attribuer ces droits.
On pourrait pour cela créer un groupe par droit spécifique, noter l’UID de ce groupe, et l’intégrer dans les développements.
Seulement ce n’est pas applicable à tous les projets, comme par exemple lorsqu’il y a un serveur de développement (pour les tests) et un serveur de production et que les UIDs ne correspondent pas.
De même, on n’est pas à l’abri qu’un administrateur supprime un groupe par erreur. Dans ce cas là, il faut modifier les UIDs en dur dans le code PHP pour les faire correspondre aux nouveaux UIDs du site.
Enfin, en fonction du nombre de droits à créer cela peut devenir un vrai casse tête au niveau des groupes et des affectations.
B) Le principe des custom permissions
TYPO3 permet, depuis la version 3.7, de palier à ce problème en permettant aux développeurs d’ajouter leurs propres droits spécifiques.
Ces droits peuvent être déclarés par n’importe quelle extension sous la forme d’une portion de code dans le fichier « ext_localconf.php »
Cette déclaration va ajouter une section dans la partie « Options de modules personnalisées » des groupes d’utilisateurs backend (dernière partie dans l’onglet « listes d’accès »).
Il est possible d’attribuer un ou plusieurs droits directement à chaque groupe, en fonction des besoins.
Au niveau du développement, il suffit de vérifier si l’utilisateur hérite bien d’un groupe avec le droit en question via une simple fonction de l’API.
C) Déclaration d’une permission spécifique
1) Déclaration de base
Les « custom permissions » sont regroupées dans le tableau $GLOBALS[‘TYPO3_CONF_VARS’][‘BE’][‘customPermOptions’].
Les droits sont regroupés autour de catégories (les types de droits).
Il est conseillé d’utiliser un code de catégorie en rapport avec le nom de votre extension pour simplifier l’identification de ces droits.
ex : tx_exemple
Voici le code de base de la déclaration :
$GLOBALS['TYPO3_CONF_VARS']['BE']['customPermOptions']['tx_exemple'] = array( //entete de la catégorie 'header' => 'Entête de la catégorie du droit', //tableau contenant la déclaration du droit 'items' => array( 'code_du_droit' => array('titre du droit'), ) );
Résultat :
2) personnalisation des informations
Il est possible de créer plusieurs droits pour chaque catégorie.
Chaque droit peut être personnalisé avec, dans l’ordre :
- un libellé (minimum requis)
- une icône
- un texte descriptif qui sera affiché lors du survole de l’icône d’aide. A savoir qu’il est possible d’avoir d’utiliser des balises HTML dans cette description.
Pour tout ce qui est libellé, il est conseillé de passer par un fichier de langue.
Cela permet de présenter des libellés dans la langue de l’utilisateur au lieu d’un texte toujours en français par exemple.
Il est donc conseillé de remplacer :
'header' => 'Entête de la catégorie du droit',
par quelque chose comme :
'header' => 'LLL:EXT:tx_newsletter/Resources/Private/Language/locallang.xlf:header',
Malgré cela, dans cet article on gardera les libellés en texte pour que cela soit plus lisible.
Si on reprend l’exemple de la Newsletter le code pourrait être :
$GLOBALS['TYPO3_CONF_VARS']['BE']['customPermOptions']['tx_newsletter'] = array( //entete de la catégorie 'header' => 'Catégorie Newsletter', //tableau contenant la déclaration des droits 'items' => array( 'AccesStatistiques' => array( 'Droit d'accès aux statistiques', //libellé 'EXT:tx_newsletter/Resources/Public/Images/icone_droit_statistiques.png', //icône 'Droit permettant à l'utilisateur d'accéder <b>aux statistiques</b> du module Newsletter', //description ), 'AccesConfiguration' => array( 'Droit d'accès à la configuration', //libellé 'EXT:tx_newsletter/Resources/Public/Images/icone_droit_configuration.png', //icône 'Droit permettant à lutilisateur d'accéder <b>à la configuration</b> du module Newsletter', //description ) ) );
Résultat :
D) procédure de vérification des droits
Pour vérifier que l’utilisateur connecté en Backoffice est bien titulaire d’un droit, il faut faire appel à l’API en appelant la fonction « check » sur un objet « backend user ».
public function check($type, $value)
Le premier paramètre permet de spécifier quel est le type de vérification.
Dans le cas des permissions spécifiques, il faut spécifier « custom_options ».
Le 2nd paramètre est la valeur à vérifier. Dans notre cas, il faut ensuite fournir la catégorie concaténée avec le code du droit à vérifier.
La valeur de retour est TRUE si l’utilisateur backend hérite bien du droit spécifié, sinon FALSE.
//permet de vérifier si l'utilisateur backoffice connecté hérite bien du droit spécifique //si on reprend l'exemple de la newsletter : catégorie "tx_newsletter" et le droit "AccesStatistiques" $retour=$GLOBALS['BE_USER']->check('custom_options', 'tx_newsletter:AccesStatistiques'); //si le droit est ok if ($retour===TRUE){ //ici le code si l'utilisateur hérite du droit }else{ //sinon //ici le code si l'utilisateur n'hérite pas du droit }
Si on reprend l’exemple d’origine, il est maintenant possible d’attribuer, groupe d’utilisateur par groupe d’utilisateur, un ou plusieurs droits spécifiques simplement.
Plus besoin de rappeler le développeur parce qu’un groupe d’utilisateur a été supprimé par erreur ou qu’il faut une nouvelle combinaison de groupes d’utilisateurs.
E) Remarques :
Cette gestion de droit n’est disponible que pour les utilisateurs Backend.
Cela signifie que l’on peut l’utiliser dans les développements backend.
Il est aussi possible d’utiliser cette fonctionnalité en frontend pour, par exemple, activer des fonctionnalités de debug lorsque l’utilisateur backend visite une page en prévisualisation.
Par contre, il n’existe pas d’équivalent concernant les utilisateurs Frontend, et c’est bien dommage.
F) Source :
TYPO3 Core API :
http://docs.typo3.org/TYPO3/CoreApiReference/ApiOverview/Examples/CustomPermissions/Index.html