Using new DJ5.1 LoginRequiredMiddleware with login_not_required erroneously redirects API call to login-page

[RobKuipers]

Using the new Django 5.1 LoginRequiredMiddleware, I ran into an issue with calling an API that uses Basic Authentication. It suddenly kept redirecting to the login-page.
So I marked my API call with @login_not_required, only to find the problem remained!

Moving the @login_not_required decorator to the top (setting it as the first decorator, before @api_view(['GET'])), circumvented the problem.
But this seems very ugly. With the need to set the @login_not_required decorator on all API's, and more importantly, having to know it needs to be first.

I'm of the opinion API-calls should never redirect to a login-page, but rather return the appropriate http-statuscode.
But, where (and how) to implement this?

Very interested in your opinions/solutions.

[thomaslrg]

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

# app/middleware.py

from django.conf import settings
from django.contrib.auth.middleware import LoginRequiredMiddleware
from django.utils.deprecation import MiddlewareMixin
import re


class CustomLoginRequiredMiddleware(LoginRequiredMiddleware):
    def __init__(self, get_response=None):
        self.get_response = get_response
        self.open_urls = [re.compile(url) for url in settings.OPEN_URLS]
        super().__init__(get_response)

    def process_view(self, request, view_func, view_args, view_kwargs):
        for url in self.open_urls:
            if url.match(request.path):
                return None  # Pass through, no login required
        return super().process_view(request, view_func, view_args, view_kwargs)

In settings.py, define OPEN_URLS and use the custom middleware:

# app/settings.py

MIDDLEWARE = [
    # ...
    "app.middleware.CustomLoginRequiredMiddleware",
]

# Regex patterns for paths that bypass LoginRequiredMiddleware
OPEN_URLS = [
    r"^/my-api/.*",
    # ...
]

I'm also very interested in opinions and solutions.

[browniebroke]

As far as I understand, it's because Django LoginRequiredMiddleware 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:

django-rest-framework/rest_framework/views.py

Lines 385 to 397 in 337ba21

	def initialize_request(self, request, *args, **kwargs):
	"""
	Returns the initial request object.
	"""
	parser_context = self.get_parser_context(request)
	return Request(
	request,
	parsers=self.get_parsers(),
	authenticators=self.get_authenticators(),
	negotiator=self.get_content_negotiator(),
	parser_context=parser_context
	)

django-rest-framework/rest_framework/request.py

Lines 378 to 395 in 8e304e1

	def _authenticate(self):
	"""
	Attempt to authenticate the request using each authentication instance
	in turn.
	"""
	for authenticator in self.authenticators:
	try:
	user_auth_tuple = authenticator.authenticate(self)
	except exceptions.APIException:
	self._not_authenticated()
	raise
	if user_auth_tuple is not None:
	self._authenticator = authenticator
	self.user, self.auth = user_auth_tuple
	return
	self._not_authenticated()

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's LoginRequiredMiddleware. AFAIK, that fits into the maintenance policy to keep up to date with newer Django features.

[browniebroke]

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 the DEFAULT_PERMISSION_CLASSES setting.