Hi Alasdair, > On 16 Mar 2020, at 12:59, Alasdair Nicol <alasd...@thenicols.net> wrote: > > Hi, > > Creating Django settings is often discouraged, so perhaps it would be better > to create a subclass of AuthenticationMiddleware instead of adding a setting. > Then users would update MIDDLEWARE to enable the new functionality.
I see, that supports my initial idea. I was planning to have new middleware but creating a subclass of AuthenticationMiddleware with a process_view function is way better. People who want to enabled that feature can directly replace AuthenticationMiddleware with our new middleware. To be honest, I’m kind a confused about how to proceed. Should I continue with settings to control it or subclass of Auth middleware ? I really want to contribute to the Django thus I’m willing to send PR for that feature, because it looks like newbie friendly in terms of implementation, but I think I need a kind of confirmation from core devs. > > Cheers, > Alasdair > > On Sunday, 15 March 2020 17:46:48 UTC, Mehmet Ince wrote: > Hi Adam, > > Thanks for your comments. I was thinking to implemented this as a separated > middleware but, as you said, AuthenticationMiddleware is much better place to > do it. > > I already started to implementing this in AuthenticationMiddleware. I would > like to send a PR if it’s okay to everyone ? > > I’m not sure it’s okay to discuss this in mailing list but I need a help > about naming convention for following variables/class/function: > > - Variable name to control this in settings.py. ( FORCE_LOGIN_REQUIRED maybe > ? ) > - Mixing name for CBV and decorator name FBV ( AnonymousUserMixin and > @anonymous_user ? ) > > Thanks, > M. > >> On 15 Mar 2020, at 17:13, Adam Johnson <m...@adamj.eu <>> wrote: >> >> Hi Mehmet, >> >> I like your move to fail-closed here. I've certainly seen missing auth >> decorators as a recurring issue in my career, and I do think as an OWASP top >> ten we should try tackle it better in the framework. >> >> Your implementation is very few lines of code. It could be made more robust, >> using the attribute approach that the CSRF middleware uses: >> https://github.com/django/django/blob/7075d27b0c75f1431f29497f4353cd742906b357/django/middleware/csrf.py#L209 >> >> <https://github.com/django/django/blob/7075d27b0c75f1431f29497f4353cd742906b357/django/middleware/csrf.py#L209> >> . And it could easily be added to django.contrib.auth, and the default >> project template. AuthenticationMiddleware doesn't in fact have a >> process_view method at current, so we could even add it there with a setting >> to control it. >> >> I doubt many would be against it as an optional extra. >> >> Thanks, >> >> Adam >> >> On Sun, 15 Mar 2020 at 06:36, Václav Řehák <reha...@gmail.com <>> wrote: >> Hi Tobias, >> >> Dne sobota 14. března 2020 9:44:16 UTC+1 Tobias Bengfort napsal(a): >> >> Another option could be to add system checks for this: Instead of >> silently "fixing" missing code it would inform developers about missing >> decorators/mixins. (If I have time I might try to come up with a >> prototype of this.) >> >> my thinking about this is exactly the same as yours. I have seen issues with >> developers forgetting to add LoginRequiredMixin almost on all projects I >> worked on and I think all of this issues would have been prevented if the >> developers were force to explicitly specify the desired authentication >> requirements for each view (probably using the checks system). >> >> In my current project we added a testcase to go through all urls in urlconf >> and compare then to whitelist of public urls. But it is ugly as it hardcodes >> urls as strings (similar to the django-utils repo) defeating the flexibility >> of url patterns. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-d...@googlegroups.com <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/4c13eb8d-eb6a-4973-be4d-5abe0fc55bb9%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/4c13eb8d-eb6a-4973-be4d-5abe0fc55bb9%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> >> -- >> Adam >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-d...@googlegroups.com <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Ui3shxaspquwhbvT0%2BrbhJXfkC4Sd8bw-zcS_2u0Q5A%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAMyDDM3Ui3shxaspquwhbvT0%2BrbhJXfkC4Sd8bw-zcS_2u0Q5A%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/f3916d6d-77c0-4e40-b201-aaabfe2abd58%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/f3916d6d-77c0-4e40-b201-aaabfe2abd58%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2828053D-2340-4C85-B354-47D0096A5ACF%40mehmetince.net.
signature.asc
Description: Message signed with OpenPGP
