Produits Entr'ouvert » Authentic 2

L'interface qu'on expose via django_rbac étant conditionnée par l'interface qu'on a envie de manipuler dans le manager, je mets les deux ensembles.

Notes informatives sur la partie rbac : on associe un niveau d'authentification à un rôle. Pour un utilisateur doté lui aussi d'un niveau d'authentification, on veut permettre de vérifier s'il a accès ou pas à certaines permissions en excluant celles données par des rôles dont le niveau est trop élevé.
Plus précisément, à la question « est-ce que l'utilisateur a ces permissions ? », on doit pouvoir répondre oui ou non comme avant, mais aussi « non, mais il pourrait les avoir avec un niveau supérieur ». Ou alors obliger à poser à chaque fois deux questions, mais ça ferait du code moche et ce n'est pas l'approche retenue ici.
Le niveau d'un utilisateur étant stocké dans sa session django (et pas dans un attribut de User facilement accessible), on permet aux méthodes de la famille User.has_perm de recevoir un nouveau kwarg auth_level, qui doit indiquer le niveau de l'utilisateur courant.
Si il n'est pas présent, tout marche comme d'habitude.
Si il est présent, on vérifie d'abord si l'utilisateur a les permissions en regardant celles données par les rôles de l'utilisateur ayant un niveau inférieur ou égal au sien. Si c'est bon, on retourne. Sinon, on vérifie à nouveau, sans filtrer les rôles. Si c'est pas bon, on retourne. Si en revanche, cette fois-ci ça passe, on lève une exception, qui informe que ça pourrait passer avec un niveau plus élevé.

Notes informatives sur la partie manager : le cas de base est très simple à gérer, on modifie légèrement le PermissionMixin. En revanche, il y a plein de cas particuliers qui font que c'est pas si joli au final. Notamment les formulaires qui s'ouvrent dans des popups : si une montée de niveau est déclenchée à ce moment là, la redirection vers la page de login va (mal) s'afficher dans la popup.

Plus d'infos dans les messages de commit :)