Hi Tobias, Thanks for your comments
> On 14 Mar 2020, at 11:43, Tobias Bengfort <tobias.bengf...@posteo.de> wrote: > > Hi Mehmet, > > On 13/03/2020 21.47, Mehmet Ince wrote: >> - We must forcefully enable session validation for every endpoint. >> - Developers must do something to make the unauthenticated endpoint >> instead of making it authentication protected! > > I agree with you that this would be a better situation from a security > standpoint. However, there are many important details that make this > harder than one might think, most of which you already mentioned. > >> - You can enable it by adding >> 'forceauth.ForceAuthenticationMiddleware' middleware. > > I would avoid the "auth" wording as it is easy to think that this is > about authorization. The corresponding mixin in django is called > `LoginRequiredMixin`, so I think it would be a good idea to call this > one `forcelogin.ForceLoginMiddleware`. I agree with that naming :). Actually I implemented this middleware just to make sure the feature is working without a problem. All the class and function names are chosen without thinking carefully. So of course we can choose better names when we start actual development of that feature. > >> - 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. > > I think it is nice that this mirrors the current situation, but the > implementation feels brittle. Wouldn't it be much easier to add a list > of ignored paths to settings? As far as I know, generic cycle is writing a view, and defining a path in url list or vice versa. Adding 3rd step like adding url in settings.py can be kind a confusing somewhere else rather than urls.py. On the other hand, if the project have lots of unauthenticated endpoint it might be hard to maintain the list. > >> I'm not talking about authorization > > This is a big one for me. In the projects that I have worked on, there > was rarely a view that required login but no permissions. So adding the > middleware could create a false sense of security. Sure, it improves the > situation quite a bit by requiring authentication, but it hides the > underlying issue. I was thinking that `ForceLoginMiddleware` will not be added to the middlewares list by default, at least for a short/mid term. If the project rarely requires a login for view, there will be a no issue. > > 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.) Idea looks great. But since I am not as much experienced Django developers as people on this mailing list, I cannot say much. On the other hand, most of the today’s web applications doesn’t suffer from SQL Injection anymore because the way people are learning software development is mostly based on official documentation. So having that feature in Django Core and mentioned about problem and how can people use that middleware can help to people know security risk even though they don’t use it at all. > > tobias > > -- > 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/defe8a05-ad60-bc66-03c8-238401e38605%40posteo.de. -- 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/E8BE209A-2F86-43D6-94EC-AD11FEEAE4BF%40mehmetince.net.
signature.asc
Description: Message signed with OpenPGP
