Hi, Actually, middlewares can access to the mapped view function/class with process_view() method. Within the function we need to decide that view is function or class. Easiest way to do it check existence of view_class attribute of view_func variable. While __global__ exist on every object, Class-based-views only have a view_class.
You can see how I managed to implemented this as a middleware at following link. https://github.com/mmetince/django-forceauth/blob/master/forceauth/__init__.py Cheers, M. > On 14 Mar 2020, at 05:21, Abhijeet Viswa <abhijeetvi...@gmail.com> wrote: > > > Hello, > > If I'm not mistaken, middlewares are not aware of decorators, mixins applied > on the request handlers. Therefore, if the middleware is turned on, there > wouldn't be a way to selectively not enforce it. At least not with > decorators/mixins. > > The rest framework uses a global setting that applies default Authentication > and Permissions classes on all views. something like that could be possible > in core Django. > > On Sat, 14 Mar, 2020, 02:18 Mehmet Ince, <meh...@mehmetince.net > <mailto:meh...@mehmetince.net>> wrote: > Hi everyone, > > I've been working as a security researcher for a long time. Common mistake > that I've seen is forgotten decorator and/or Mixin usage on controllers, > which leads to OWASP A5 Broken_Access_Control[1]. I believe one of the most > important, as well as most used, decorator and/or Mixing in Django world is > @login_required. > > Instead of calling that decorator on every single function-based-view is kind > a against the DRY. Also even sometimes it's possible to forgot to call > decorator, which is scary. For class-based-view it's usually requires to > define an abstract controller class, where you call login_required decorator > with method_decorator on dispatch method[2]. Of course that approach makes > sense and looks like a proper design decision but it still leaves some open > doors. For instance, what would happen if new contributor/developer in the > team inherits TemplateView directly instead of ProtectedView class ? etc etc > etc. > > Since almost %90 of the endpoint of todays web application requires an > authentication -I'm not talking about authorization-, I believe we should be > writing code in order to make endpoint accessible by unauthenticated request. > > So my proposal is very simple: > > - We must forcefully enable session validation for every endpoint. > - Developers must do something to make the unauthenticated endpoint instead > of making it authentication protected ! > - We should do this in middlewares. Because for my opinion, such as > validation and check should be done way before execution reaches to the views. > > Technical implementation can be as follow: > > - You can enable it by adding 'forceauth.ForceAuthenticationMiddleware' > middleware. Otherwise Django can work as it. > - If you have a FBV, and it requires to be accessible for unauthenticated > users, call @publicly_accessible_endpoint decorator. > - If you have CBV, and it requires to be accessible for unauthenticated > users, inherit PubliclyAccessibleEndpointMixin along side other classes that > you need like TemplateView,ListView etc. > - All the other endpoints will be protected by authentication validation on > middleware. > > You can see my initial implementation at > https://github.com/mmetince/django-forceauth > <https://github.com/mmetince/django-forceauth> and read my all thoughts > regarding to the approach to the session validation at blog post [3]. > > [1] > https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control > > <https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A5-Broken_Access_Control> > [2] > https://docs.djangoproject.com/en/3.0/topics/class-based-views/intro/#decorating-the-class > > <https://docs.djangoproject.com/en/3.0/topics/class-based-views/intro/#decorating-the-class> > [3] > https://pentest.blog/why-secure-design-matters-secure-approach-to-session-validation-on-modern-frameworks-django-solution/ > > <https://pentest.blog/why-secure-design-matters-secure-approach-to-session-validation-on-modern-frameworks-django-solution/> > > PS: This is my first mail to Django mailing list, if it’s wrong place to > discuss such a ideas please let know where to do it properly :) > > -- > 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/F6FB68F9-9287-45BD-B3AD-F59C2B4E23F0%40mehmetince.net > > <https://groups.google.com/d/msgid/django-developers/F6FB68F9-9287-45BD-B3AD-F59C2B4E23F0%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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAP1-YrprcKUmLYd3CJUVWJD22jOLHWR1rO3pVZGe601Bg9%2Bd8g%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAP1-YrprcKUmLYd3CJUVWJD22jOLHWR1rO3pVZGe601Bg9%2Bd8g%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/85F01CC7-E304-4C43-B38E-4B6421267352%40mehmetince.net.
signature.asc
Description: Message signed with OpenPGP
