The oldest code at https://djangosnippets.org that fixes this is from 2008 so I guess something like this have been considered trivial to build yourself ever since then, and hence why it's never been added. Here are some alternatives:
https://djangosnippets.org/search/?q=login+required I've been using some variation on LoginRequiredMiddleware since 2008 myself, see: https://gist.github.com/hmpf/0d8faf83e7c7d868126d7c60c8dd0b6a Some way to open up urls by string is generally necessary for 3rd party apps otherwise I wouldn't bother to have the PUBLIC_URLS setting. API's often use a separate authentication mechanism, so best exempt those too. Any officially supplied login views should mark themselves as exempt so they don't pollute PUBLIC_URLS though. Most of my Django sites have only cared about whether you are logged in or not, then have an "owner" foreign key on models that can be CRUDed by users. I much prefer roles to permissions since I used to do a lot with Zope 2. On Thu, 19 Mar 2020 at 14:25, Fabio Caritas Barrionuevo da Luz <bna...@gmail.com> wrote: > > > > I'm surprised nobody has mentioned django-stronghold in this discussion > > which does exactly what you're looking for. > > Same here. django-stronghold has been working well in my projects for me for > years. > > https://github.com/mgrouchy/django-stronghold > > > > Em quinta-feira, 19 de março de 2020 07:41:35 UTC-3, Matt Magin escreveu: >> >> 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 <alas...@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. >>>> >>>> >>>> >>>> -- >>>> 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. >>>> >>>> >>> >>> -- >>> 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/f3916d6d-77c0-4e40-b201-aaabfe2abd58%40googlegroups.com. >>> >>> >>> -- >>> 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/2828053D-2340-4C85-B354-47D0096A5ACF%40mehmetince.net. > > -- > 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/651f48c0-dcab-48aa-812a-24ca2c0f7a9f%40googlegroups.com. -- 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/CACQ%3DrreXtncG31z1MhB94AVykFjPKaTJXN%3DyOyomLxvK275BBg%40mail.gmail.com.
