I'm not sure this is the best solution, but you can create a custom middleware that bypassesLoginRequiredMiddleware for specific URL patterns using regex.django-stronghold had the same type of functionality.

# app/middleware.pyfromdjango.confimportsettingsfromdjango.contrib.auth.middlewareimportLoginRequiredMiddlewarefromdjango.utils.deprecationimportMiddlewareMixinimportreclassCustomLoginRequiredMiddleware(LoginRequiredMiddleware):def__init__(self,get_response=None):self.get_response=get_responseself.open_urls= [re.compile(url)forurlinsettings.OPEN_URLS]super().__init__(get_response)defprocess_view(self,request,view_func,view_args,view_kwargs):forurlinself.open_urls:ifurl.match(request.path):returnNone# Pass through, no login requiredreturnsuper().process_view(request,view_func,view_args,view_kwargs)

Insettings.py, defineOPEN_URLS and use the custom middleware:

# app/settings.pyMIDDLEWARE= [# ..."app.middleware.CustomLoginRequiredMiddleware",]# Regex patterns for paths that bypass LoginRequiredMiddlewareOPEN_URLS= [r"^/my-api/.*",# ...]

I'm also very interested in opinions and solutions.

As far as I understand, it's because DjangoLoginRequiredMiddleware kicks in before the DRF view-level auth happens, so as far as Django is concerned, the HTTP request isn't authenticated until the DRF logic kicks in, which AFAIU is done at the view level:

calling an API that uses Basic Authentication

I would be curious if you see the same behaviour with session auth. My expectation is that it would work, because this relies on a Django built-in auth mechanism, while the others (Basic and token based auth) are DRF specific.

With regards to solutions, one might be for DRF to provide a specialized version of Django'sLoginRequiredMiddleware. AFAIK, that fits into the maintenance policy to keep up to date with newer Django features.

I've dug this a bit more to attempt to add compatibility to DRF as part of#9514 and just realised that DRF already offers a way to make sure all endpoints are authenticated, via theDEFAULT_PERMISSION_CLASSES setting.

@browniebroke Came accross this, since I was thinking weather I should be using DRFDEFAULT_PERMISSION_CLASSES or a django middleware (concerning login-required functionality; my custom authenticated user checks, such as email-verified, policy-agreed etc.; and specific permission checks for individual views, e.g. roles). And I noticed this in the docs:
Note: when you set new permission classes via the class attribute or decorators you're telling the view to ignore the default list set in the settings.py file.
Which if being the case, doesn't satisfy my use case, since I wanna stack permission checks (login-required + authenticated-related-almost-ubiquitous-checks + individual-view-checks), not overwrite them. And specifying all of them at view-level results in a lot of duplication and is error-prone. At first glance a quick solution to this might be to subclassBasePermission, but I felt hesitant going this way as middleware approach seemed cleaner. Please fix me if I misunderstood smth, but it looks like for my use case I'll have to work at django middleware level andLoginRequiredMiddleware ain't gonna help much. :)