Le Mad Blog

Le CSRF , mais pourquoi faire ?

Imaginons, juste comme ça hypothétiquement, que vous vouliez désactiver de manière globale la protection CSRF sur la totalité des urls d’un site django.

Vous pensez qu’il suffit de désactiver le middleware qui va bien (soit django.middleware.csrf.CsrfViewMiddleware ) pour que op c’est bon, la vérification CSRF n’est plus mise en place ?

Vous serez alors décontenancé de voir que non, cela ne suffit pas. Il faut aussi ajouter le décorateur csrf_exempt ( qui se trouve dans django.views.decorators.csrf ) sur chacune de vos urls. Un peu compliqué en vrai, surtout si vous avez beaucoup d’urls. _

Comment faire ?

Tout simplement coder un middleware qui va l’enlever pour vous. Vous n’aurez ensuite qu’à le déclarer dans les middleware actifs.

class NOCSRFMiddleware(object):

def __init__(self, get_response):

        self.get_response = get_response



    def __call__(self, request):

        setattr(request, '_dont_enforce_csrf_checks', True)

        response = self.get_response(request)

        return response

Et voila ! Il suffit ensuite de le déclarer dans MIDDLEWARE et le tour est joué ( par exemple avec un  BadIdeaApp.BadMiddleware.NOCSRFMiddleware

Groupons, Groupons, Groupons !!!

J’avais totalement oublié l’existence du templatetags regroup qui permet de regrouper des objets identique par un attribut commun. Comme regrouper une liste de dictionnaires par les valeurs de l’un des attributs. La documentation complète est disponible ici : https://docs.djangoproject.com/en/4.2/ref/templates/builtins/#regroup

Et redécouvrir ce templatetags m’a été bien utile. Surtout en le couplant avec un autre templatetags que j’avais également oublié, dicsort ( https://docs.djangoproject.com/fr/4.2/ref/templates/builtins/#std-templatefilter-dictsort) qui va trier une liste de dictionnaire par une des clés des dictionnaires.

Longtemps que je n’avais pas posté de billets dans cette partie du blog. (Vous allez me dire longtemps que je n’ai pas posté de billet tout court, et vous auriez raison, mais ma bonne résolution de fin de vacances d’été est de changer cela).

Mais donc, pour reprendre doucement dans la partie technique, je vais commencer par partager un truc que tout le monde connaît sûrement déjà. Sauf que perso, j’oublie à chaque fois que cette fonctionnalité de django existe et donc je galère pour la retrouver. Du coup je me dis qu’en l’écrivant je finirais par la mémoriser (et donc en fait j’écris plus pour moi qu’autre chose, je suis un vilain !:) ).

Donc imaginons que vous avez un modèle. Truc assez classique. Ce modèle vous lui avez défini une représentation textuelle de base avec str . Sauf que vous avez plusieurs forms, donc certains ont des ChoiceFields utilisant ce modèle (Exemple un modèle User et vous avez un modèle Post où vous devez choisir le rédacteur du billet). Et manque de chance, vous avez besoin d’une représentation textuelle différentes de celle de base pour un de vos forms. Où même pire, vous avez besoin de plusieurs représentations textuelles différentes, pour plein de forms différents.

Vous êtes alors bien marri.

Mais en fait non, parce que Django vous fourni une façon à la fois simple et élégante de faire. A chaque fois que vous aurez besoin d’une représentation textuelle qui ne soit pas celle par défaut, il vous suffira de définir une classe dérivant de ModelChoiceField et qui implémentera la méthode label_from_instance. Cette méthode prend comme unique paramètre l’objet qui doit voir sa représentation textuelle définit et renvoie une chaîne de caractère.

Petit exemple tiré de la doc django :

Voilà. Aussi simple que cela. Vous n’avez plus qu’à utiliser votre classe fille de ModelChoiceField dans votre formulaire et le tour et joué.

Bonus, ça marche aussi pour les MultipleChoiceField, il faudra simplement définir une classe fille de ModelMultipleChoiceField

et le lien vers la doc qui parle de tout cela : (https://docs.djangoproject.com/fr/2.0/ref/forms/fields/)