DRF Middleware proposal

[al-muammar]

Problem

There is a well-known problem described in https://stackoverflow.com/questions/26240832/django-and-middleware-which-uses-request-user-is-always-anonymous. In a nutshell, you can't get request.user in any of the django middlewares. This is a really important missing feature, as I would like to perform some actions for all of my APIViews (and not only them).

For example, I want to:

• activate language (which is stored in my user model)
• activate timezone (which is stored in my user model)
• Implement any custom logic, like sending events for some analytics

Hack

Right now, the best solution I have is to inherit from my authentication class and override authenticate method by adding there some custom logic. Also, it doesn't really work for handling responses.

Idea

I think would be nice to have some kind of DRF Middleware and then Authentication, Permissions and Throttling implemented in this way. Then a user might add as many as they want custom middlewares. It is also will be better aligned with django design.

The idea is super-raw, so dismiss it by any chance, if you have something better. However, the problem is real, so let's use this issue to kick off the discussion and maybe we will come up with something reasonable. Thanks!

[Real-Gecko]

So, two years has passed and still no progress?

[auvipy]

I would love to see some examples

[JasperSui]

I'm facing this problem as well.

The thing is here the request of request.user doesn't mean the same class sometimes.

from django.http import HttpRequest  # Django request

from rest_framework.request import Request # DRF request

Mostly, the django can't aware of the existence of DRF request, IMO, this is one of the trade-offs for extending django.

So, if I have to do something after the user or the owner of the request is authenticated in DRF APIView classes, I have to do it manually in the custom authentication classes and add it to settings.REST_FRAMEWORKS["DEFAULT_AUTHENTICATION_CLASSES"] to do things I want, which doesn't make sense since it's called "authentication classes" instead of "middlewares".

Of course we can get the user of requests in django middlewares like how django.contrib.auth.AuthenticationMiddleware does:

# Ref: https://github.com/django/django/blob/stable/4.2.x/django/contrib/auth/middleware.py#L15-L25

from django.contrib import auth
from django.utils.functional import SimpleLazyObject

def get_user(request):
    if not hasattr(request, "_cached_user"):
        request._cached_user = auth.get_user(request)
    return request._cached_user

class AuthenticationMiddleware(MiddlewareMixin):
    def process_request(self, request):
        if not hasattr(request, "session"):
            raise ImproperlyConfigured(
                "The Django authentication middleware requires session "
                "middleware to be installed. Edit your MIDDLEWARE setting to "
                "insert "
                "'django.contrib.sessions.middleware.SessionMiddleware' before "
                "'django.contrib.auth.middleware.AuthenticationMiddleware'."
            )
        request.user = SimpleLazyObject(lambda: get_user(request))

by implementing or using the django authentication backends e.g. ModelBackend:

# Ref: https://github.com/django/django/blob/stable/4.2.x/django/contrib/auth/backends.py#L159-L164
class ModelBackend(BaseBackend):
    """
    Authenticates against settings.AUTH_USER_MODEL.
    """

    # (...)

    def get_user(self, user_id):
        try:
            user = UserModel._default_manager.get(pk=user_id)
        except UserModel.DoesNotExist:
            return None
        return user if self.user_can_authenticate(user) else None

then, implement a DRF authentication class which will access the django HttpRequest object and get the user set by the django middleware just like how rest_framework.authentication.SessionAuthentication does:

# Ref: https://github.com/encode/django-rest-framework/blob/3.14.0/rest_framework/authentication.py#L112-L133
class SessionAuthentication(BaseAuthentication):
    """
    Use Django's session framework for authentication.
    """

    def authenticate(self, request):
        """
        Returns a `User` if the request session currently has a logged in user.
        Otherwise returns `None`.
        """

        # Get the session-based user from the underlying HttpRequest object
        user = getattr(request._request, 'user', None)

        # Unauthenticated, CSRF validation not required
        if not user or not user.is_active:
            return None

        self.enforce_csrf(request)

        # CSRF passed with authenticated user
        return (user, None)

You can see DRF get the user from the request._request.user, after the translation of classes, it'll be (rest_framework.request.)Request.(django.http.)HttpRequest.user.

Although we can post-process the requests of DRF after DRF authentication flow by customizing the authentication classes, but we still can't post-process the responses of DRF since the authentication classes will be used once only when the rest_framework.request.Request is instantiated by APIView.dispatch(), so there is no chance for us to post-process the responses in DRF, if you are interested in the lifecycle of the request and response of Django and DRF, you can reference to the image drawed by Sourcery (BTW, it's really nice for people to understand the whole picture of Django & DRF in few minutes).

So I think if we can have the DRF middleware mechanism that can play like Django middleware, it'll definitely give us more flexibility.

BTW, if you can read Chinese, here is my two cents on Django & DRF authentication, also, welcome to have a discussion if you're suffering from the same thing.

[auvipy]

I would be happy to see any Proof of concept implementation with examples. But that should not break anything in DRF in principle.

[JasperSui]

@auvipy I've created a small PR #9090 to showcase my expectations, would you help review it?

[Anmol-techie]

I don't want to use any authentication django provides, why is still the authentication is happening even after i override the user to admin inside the middleware.

MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
# 'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'corsheaders.middleware.CorsMiddleware',
"turtle_doc.middlewares.super_admin_user_middleware"
]

REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': [], # Disable DRF authentication globally
'DEFAULT_PERMISSION_CLASSES': [
'rest_framework.permissions.AllowAny',
],
}

def set_super_admin_role(user):
"""
Modify the fetched user to act like a Super Admin.
"""
user.role = UserRoles.SuperAdmin.value
user.is_super_admin = True
user.is_superuser = True
return user

def create_super_admin_user(email):
"""
Create a new instance of the custom User model with Super Admin privileges.
This is used when no user is found by email.
"""
user = User(
first_name="Super",
last_name="Admin",
email=email, # Use the provided email or a default one
role=UserRoles.SuperAdmin.value,
is_super_admin=True,
auth_user_id="superadmin123", # Some unique ID for the user
verification_status=0, # Assuming 0 means not verified
)
user.is_superuser = True
user.is_authenticated = True # Treat this user as authenticated for middleware
return user

def super_admin_user_middleware(get_response):
def middleware(request):
super_admin_email = "[email protected]"

    try:
        # Try fetching the Super Admin user
        user = User.objects.get(email=super_admin_email)
        request.user = set_super_admin_role(user)
    except User.DoesNotExist:
        # If not found, create a super admin user instance
        request.user = create_super_admin_user(super_admin_email)

    print("request__user__",request.__dict__)
    return get_response(request)

return middleware

[Anmol-techie]

@JasperSui pls check above

onse solution i found was try assigning the admin user inside the view class again:-
try:
admin_user = User.objects.get(email='[email protected]')
request.user = admin_user
except User.DoesNotExist:
return Response({'error': 'Admin user not found'}, status=status.HTTP_500_INTERNAL_SERVER_ERROR)

[Anmol-techie]

@JasperSui i also tried overriding the perform_authentication, that worked too

def perform_authentication(self, request):

    try:
            admin_user = User.objects.get(email='[email protected]')
            request.user = admin_user  
    except User.DoesNotExist:
            return Response({'error': 'Admin user not found'}, status=status.HTTP_500_INTERNAL_SERVER_ERROR)

[davidemerritt]

+1 to this idea, I am running into the same issue where I would like to do language activation at the middleware level where the logic is determined on the user properties.

Hacking authentication out from the DRF implementation (I am using token authentication) works but incurs an additional DB query cost for the reasons detailed above where the request.user is not shared between the django request and the DRF.request model if it is already instantiated in a middleware.

[JasperSui]

You can use request._request.user in drf authentication classes to get the user authenticated by django, and it won't query again since django has cached it in django request object, hope it helps.

[davidemerritt]

Thanks I will check it out!