Flaz's Hotline

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Password_policy ======
===== Moins simple qu'il n'y paraît =====
Ce module permet d'implémenter une politique de sécurité. Les fonctionnalités de bases ainsi que les limites sont bien expliquées, tant dans la [[https://www.drupal.org/project/password_policy|page du module]] que dans la documentation qui n'est autre que le fichier //README.txt// situé à la racine du répertoire du module.

L'utilisation paraît limpide mais on, déchante lorsqu'on veut configurer le module. On se heurte à des formulations d'une invraisemblable opacité((On dirait du coréen traduit en espagnol via //google trad// puis retraduit en anglais par un francophone :-))). Voici donc, l'explication des points les plus obscurs.
===== Principe général d'expiration des mots de passe =====
On peut définir plusieurs politiques de mots de passe, chacune ayant une durée d'expiration différente. La question posée est : que se passe-t-il si je modifie une politique de sécurité ? Le module propose deux options :
  * La durée de validité des mots de passe des utilisatrices concernées n'est pas modifiée. Elles ne devront appliquer la nouvelle politique que lorsque leur mot de passe arrivera naturellement à expiration.
  * Les utilisatrices concernées voient leur mot de passe expirer immédiatement. Elles devront donc changer leur mot de passe lors de leur prochaine connexion((Ou passeront à l'état "bloqué", suivant le choix fait, par ailleurs.)). Ce faisant, elles devront se conformer à la nouvelle version de la politique de sécurité.

En gros, la première option dit : la politique de sécurité s'appliquera lorsqu'elle doit s'appliquer, au regard de l'ancienneté des mots de passe existants. Le seconde option dit : la politique de sécurité s'appliquera dès qu'une utilisatrice concernée tente de se connecter.

On regrettera qu'en cas de choix de la deuxième option, un courriel ne soit pas envoyé aux utilisatrices concernées.
===== Caractères obligatoires =====
Pour une politique donnée, il est possible de définir quels type de caractères devront être utilisés et combien de caractères de chaque type. Jusque là, tout va bien.

Le problème vient ce que le module distingue : les lettres, les chiffres, les caractères alphanumériques et les signes de ponctuation, les lettres minuscules et les lettres capitales. Déjà, ce n'est pas très distinctif. Par exemple "a" est à la fois une lettre, un caractère alphanumérique et une lettre minuscule. Comment la décrire ?

En pratique, cela permet de faire des configurations très fines mais quelques exemples n'auraient pas été superflus. On peut ainsi signifier qu'un mot de passe doit comporter au moins 3 lettres, au moins 1 minuscule et au moins 1 capitale. Dans ce cas, l'utilisatrice aura le choix d'utiliser au moins 2 minuscules et 1 majuscule ou au moins 2 majuscules et 1 minuscule.

Une dernière option vient encore compliquer la compréhension : le nombre de types de caractères. On peut imposer que le mot de passe comprenne au moins 1, 2 3 ou 4 des types de caractères suivants : minuscules, majuscules, chiffre, ponctuation. Jusque là, tout va bien. Mais quelles sont les règles de préseance si je n'exige que 2 types et que j'indique, par ailleurs, que le mot de passe doit contenir au minimum une majuscule, au minimum une majuscule et au minimum 2 chiffres ? La documentation est totalement muette sur ce point. Il ne vous reste la rétro-spécification par essai-erreur :-(

===== Quelques pièges et oublis =====
==== Texte des courriels d'annonce d'expiration ====
Le texte du message d'annonce est en anglais mais il n'est pas pris en charge par le module d' internationalisation. Il faut donc modifier le texte dans la de configuration elle-même((Pas des la page de personnalisation des traductions, comme ça devrait l'être.)).
==== Activation de la politique de sécurité ====
Une politique n'est active que si on a pensé à cocher la case ad hoc !

==== Tests de rendu des messages ====
Ne serait-ce que pour s'assurer que les jetons (tokens) sont correctement interprétés, on fera des tests d'envoi de messages. **Evitez les messageries comme Gmail**((D'une manière générale, évitez Gmail :-P)) qui ont le chic pour classer ce type de message dans un classeur improbable. Cela vous évitera de perdre du temps en vous demandant - à tort - pourquoi le mail n'a pas été envoyé…