Should I remove CsrfViewMiddleware from MIDDLEWARE when using TokenAuthentication in DEFAULT_AUTHENTICATION_CLASSES?

[luiscastillocr]

Hello ladies and gentlemen,

I recently started to upgrade an old Django stack from 1.11.X to 2.2, the thing is there is this API(token authenticated) that suddently started to fail with CSRF Failed: CSRF cookie not set. on every non secure request(PUT, PATH, POST, etc) so tracking the error i found out the CsrfViewMiddleware middleware class is the culprit of the problem, so basically it checks if the CSRF cookie exists on the process_request method failing the request since there is nothing that has previounsly set the cookie to make it exists during the request. so since the middleware runs before the authentication classes in DRF, there is no way you can validate the user and bypass the cookie validation from the authenticator so, the most obvious solution is to disable CsrfViewMiddleware from the middleware and let the authenticator to handle the user session but i know disabling the CsrfViewMiddleware is a potential security risk, so my question is, what are the correct django middleware classes to use when you authenticate the user using a token?

Here are some aditional details:

All the API views are Class based views

Django==2.2
djangorestframework==3.13.1

MIDDLEWARE = [
    ...
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'common.tracking.middleware.CustomVisitorTrackingMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    ...
]

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.TokenAuthentication',
    ),
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
        'common.api.permissions.DisableOptionsPermission'
    ),
    'DEFAULT_RENDERER_CLASSES': (
        'rest_framework.renderers.JSONRenderer',
    ),
    'DEFAULT_PARSER_CLASSES': (
        'rest_framework.parsers.JSONParser',
    ),
    'DEFAULT_FILTER_BACKENDS': (
        'django_filters.rest_framework.DjangoFilterBackend',
        'rest_framework.filters.OrderingFilter'
    ),
    'ORDERING_PARAM': 'sort',
    'DEFAULT_PAGINATION_CLASS': 'common.api.serializers.CustomPageNumberPagination',
    'PAGE_SIZE': 10,
    'MAX_PAGE_SIZE': 10,
    'FORM_METHOD_OVERRIDE': None,
    'FORM_CONTENT_OVERRIDE': None,
}

Thanks

[jerinpetergeorge]

Are you sure the view is not using the SessionAuthentication? IIRC, DRF won't enforce a CSRF check unless you're using SessionAuthentication

[luiscastillocr]

Hi @jerinpetergeorge pretty sure of that, in the original post/question you can see the REST_FRAMEWORK settings.

I ended up doing this, I feel this is not right but it was the only thing i could come up with to solve the issue.

I am happy to provide more details in order to solve this in the right way

Thanks

class CustomCsrfViewMiddleware(CsrfViewMiddleware):
    API_ROOT = '/api/'
    PATH_INFO_KEY = 'PATH_INFO'

    def process_request(self, request):
        path = request.META.get(self.PATH_INFO_KEY, '')
        if path.startswith(self.API_ROOT):
            """
            Since we are not using the Django Session in our API and the authentication is 
            handled by our custom DRF token authenticator, there is no need to keep Django 
            looking for the CSRF on API specific unsecure requests, not completely sure 
            about this so, I asked here for advise https://github.com/encode/django-rest-framework/discussions/8792
            keep checking and hope someone with more experience can shred light on this, in 
            the meantime this is what we are gonna do to solve the issue 
            """
            setattr(request, '_dont_enforce_csrf_checks', True)
        super(CustomCsrfViewMiddleware, self).process_request(request)

[jerinpetergeorge]

I'm happy to have a look at a simple project that replicates the issue. Would you mind creating one for us? Please don't forget to include the requirements.txt file :) @luiscastillocr

[luiscastillocr]

Hey @jerinpetergeorge thanks for the quick reply, the project is pretty big with lots of dependencies included some inhouse packages (i am sure they don't have nothing to do with the issue), but here are the code bits i think complete the scenario

Django==2.2
django-cors-headers==3.11.0
djangorestframework==3.13.1
django-daterange-filter==1.3.0
django-filter==21.1

from rest_framework.generics import ListCreateAPIView
from rest_framework.permissions import IsAuthenticated
from .serializer import MyModelSerializer
from .models import MyModel

class OffendedListCreateListApiView(ListCreateAPIView):
    permission_classes = (IsAuthenticated,)
    serializer_class = MyModelSerializer
    queryset = MyModelSerializer.objects.all()
    model = MyModel

class DisableOptionsPermission(BasePermission):
    """
    Global permission to disallow all requests for method OPTIONS.
    """
    def has_permission(self, request, view):
        if request.method == 'OPTIONS':
            return False
        return True

# We are overwriting this class to have the page number,
# instead of the next and prev page links
class CustomPageNumberPagination(PageNumberPagination):

    page_size_query_param = 'page_size'

    def get_next_link(self):
        if not self.page.has_next():
            return None
        return self.page.next_page_number()

    def get_previous_link(self):
        if not self.page.has_previous():
            return None
        return self.page.previous_page_number()

    def get_paginated_response(self, data):

        return Response(OrderedDict({
            'links': {
                'next': self.get_next_link(),
                'prev': self.get_previous_link()
            },
            'total_count': self.page.paginator.count,
            'objects': data
        }))

MIDDLEWARE = [
    ...
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'common.tracking.middleware.CustomVisitorTrackingMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    ...
]

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework.authentication.TokenAuthentication',
    ),
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
        'common.api.permissions.DisableOptionsPermission'
    ),
    'DEFAULT_RENDERER_CLASSES': (
        'rest_framework.renderers.JSONRenderer',
    ),
    'DEFAULT_PARSER_CLASSES': (
        'rest_framework.parsers.JSONParser',
    ),
    'DEFAULT_FILTER_BACKENDS': (
        'django_filters.rest_framework.DjangoFilterBackend',
        'rest_framework.filters.OrderingFilter'
    ),
    'ORDERING_PARAM': 'sort',
    'DEFAULT_PAGINATION_CLASS': 'common.api.serializers.CustomPageNumberPagination',
    'PAGE_SIZE': 10,
    'MAX_PAGE_SIZE': 10,
    'FORM_METHOD_OVERRIDE': None,
    'FORM_CONTENT_OVERRIDE': None,
}

As you can see the view has nothing crazy and the implementation is very straight forward, i am almost convinced the issue is not at the view level, as I mentiened before I think the issue recides at the middleware request_process level, where the CsrfViewMiddleware expects to find the CSRF cookie during the POST request, also keep in mind I cannot make the client to send the X-CSRFToken header because again, the cookie is not present before or during the request so they cannot read the cookie and send the token in the request's headers.

From what I've found after some debugging the issue goes as follows:

1. Client(you can use postman) makes a POST request to the endpoint /view/endpoint/
2. Client request reaches the CsrfViewMiddleware.process_request middleware class method, here is where the middleware looks for the cookie, as we know the cookie is not there so request.META['CSRF_COOKIE'] is None.
3. Client request reaches the CsrfViewMiddleware.process_view here is where the request fails cause the the request.META['CSRF_COOKIE'] comes with a None value and the POST doesn't contain the csrfmiddlewaretoken field and X-CSRFToken header is either present.
4. The cookie cannot be set because the request does not reach the process_response where the cookie is supposed to be saved in the browser session.
5. I doubt the issue has something to do with the authorizer since the request never reaches the authorizer or the permissions class in the view.

Hope this can give you an scenario you can use to reproduce the issue.

Thanks again

[jerinpetergeorge]

Actually, I didn't ask for an "existing project", I asked for a minimal reproducible example (MRE).

This usually helps in two ways -

• you may identify the issue while creating the example
• people like me don't have to do anything to create the MRE and are thus ready to debug stage.

[luiscastillocr]

gotcha, let me see if I put something together.

Thanks again