Hi all, I'm surprised nobody has mentioned django-stronghold in this discussion which does exactly what you're looking for.
It's implemented as a middleware, with two settings for exclusions -- A list of named url's or a list of regex's to match url's against. This works well, and managing the exclusions through settings is not a big deal. Having said that, I do like the idea of putting it inside the Auth middleware as well. +1 from me to put this into core functionality, I include django-stronghold in basically all my projects already. Cheers, Matt On Thu, Mar 19, 2020 at 7:19 PM Mehmet Ince <meh...@mehmetince.net> wrote: > 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 >> . 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. > 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 > <https://groups.google.com/d/msgid/django-developers/2828053D-2340-4C85-B354-47D0096A5ACF%40mehmetince.net?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/CALr_n0r8sibxfNL5oGziUVnNci8c_QZc2w0S0Ug%2B-Q0EwY7jKg%40mail.gmail.com.
