Sécurité: activation de l'intergiciel LoginRequiredMiddleware

[xavfernandez]

🤔 Pourquoi ?

Pour avoir des vues protégées par défaut (en gardant en tête qu'être authentifié n'apporte aucune garantie, vu la facilité à se créer un compte).

🍰 Comment ?

Les débats à trancher:

• pour les Class Based Views:

  • utilisation d'un décorateur sur le dispatch
  • ou définition/utilisation d'un mixin pour décorer dans as_view

  => la seconde solution me semble plus propre/claire

• pour les vues utilisant un user_passes_test pour rediriger les utilisateurs loggés vers une autre vue: cela rentre en conflit avec l'intergiciel, qui utilise le login_url défini par ce décorateur pour rediriger lors de l'authentification ce qui n'est pas du tout ce que l'on souhaite:

  • soit utilisation de mon unset_login_redirect
  • soit redéfinition d'un décorateur maison qui fait le redirect
  • soit incorporation de ce check dans les différentes vues

  => je serais plutôt en faveur d'un décorateur maison qui aurait le mérite, comme user_passes_test actuellement de mettre en évidence les utilisateurs susceptibles d'accéder à cette vue)

🚨 À vérifier

• Mettre à jour le CHANGELOG_breaking_changes.md ?

🏝️ Comment tester

Les instructions pour reproduire le problème, les profils de test, le parcours spécifique à utiliser, etc. Si vous disposez d'une recette jetable, mettre l'URL pour tester dans cette partie.

💻 Captures d'écran

[francoisfreitag]

À se demander si on ne voudrait pas un LoginNotRequiredMixin ? (réponse C de la 1ere question 😛)

[xavfernandez]

Tu veux dire la réponse B/ce Mixin ?

[francoisfreitag]

Oui, mis à part que j’aurais décoré dispatch pour être symmétrique avec le LoginRequiredMixin de Django. 🤷

[xavfernandez]

Alors oui et non.
Le LoginRequiredMixin fait des choses dans le dispatch.
Alors que le LoginNotRequiredMixin.dispatch ne ferait rien.
Le but est vraiment de mettre l'attribut login_required à False sur la vue retournée par as_view() pour que LoginRequiredMiddleware la laisse tranquille.
Et Django autorise de décorer la fonction dispatch mais à la fin il fait juste https://github.com/django/django/blob/5.1.3/django/views/generic/base.py#L115-L117 🙈

[rsebille]

👍 pour le mixin, je trouve que ça fait bizarre de devoir utiliser un décorateur sur une méthode très spécifique (et pas forcément surcharger) dans le cas des CBV.

[francoisfreitag]

Hummm, merci pour l’explication. Dans ce cas, 2. (as_view) me semble également préférable.

[rsebille]

Vu qu'on à clairement plus de vue connectée que non-connectée ça me semble OK comme logique.

[rsebille]

👍 pour le mixin, je trouve que ça fait bizarre de devoir utiliser un décorateur sur une méthode très spécifique (et pas forcément surcharger) dans le cas des CBV.

[tonial]

C'est tellement cool que le middleware gère la vérification avant le setup des vues :)

[calummackervoy]

👍

[calummackervoy]

Ça simplifie des choses ! 🧹

Je vois que t'as pris en compte les vues qu'on surcharge de django-allauth par example, et qu'ils utilisent @method_decorator(login_not_required, name="dispatch") sur leurs vues clés, comme email_verification_sent

T'as pris en compte l'impact sur les vues des autres dépendances ?

[EwenKorr]

👍 pour les user.is_authenticated qui sautent !

[xavfernandez]

T'as pris en compte l'impact sur les vues des autres dépendances ?

Bonne remarque et cela me fait me rendre compte qu'on importe beaucoup de vue de allauth (18 URLs) & anymail (24 URLs).

Je vais sûrement faire une autre PR pour en exposer un peu moins => c'est fait pour anymail: #5253