4

I am building a django server for an API that relies on JWT (or Token based - https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication) authentication for our users.

I don't need session based authentication for any purpose. It creates an unnecessary query on each request, and also authenticates users when I don't want to authenticate them (I want browsers to only authenticate when it includes an Authentication header in the request, and stay AnnonymousUser otherwise. This is because it creates issues in some of my middlewares where I verify if I am dealing with a guest or a authenticated user).

However, the issue comes when I try to use the admin application as well (I can't imagine building this app without the use of the django admin page). When I remove the session-related middlewares:(django.contrib.sessions.middleware.SessionMiddleware, django.contrib.auth.middleware.AuthenticationMiddleware and django.contrib.messages.middleware.MessageMiddleware) from my settings file, I get the following error when I do a runserver:

ERRORS:
?: (admin.E408) 'django.contrib.auth.middleware.AuthenticationMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E409) 'django.contrib.messages.middleware.MessageMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E410) 'django.contrib.sessions.middleware.SessionMiddleware' must be in MIDDLEWARE in order to use the admin application.

Can someone think of a workaround where I can disable sessions in Django, while also being able to use the admin panel? One solution I thought of is to hack up adding the authorization header to each admin page request, but 1) I have no idea how to proceed with this idea and 2) (more importantly), I cannot do a runserver while disabling the session middlewares.

Julian Sam
  • 71
  • 3
  • 2
    It will not create an extra query per request. The `request.user` is a *lazy* property. That means that as long as the view does *not* need `request.user`, it will not make a query. – Willem Van Onsem Apr 11 '21 at 21:22
  • You don't need to disable them. When not used they does not cause any performance impact, and are totally ignored by DRF when accessing API views. – Dan Yishai Apr 11 '21 at 21:37
  • @WillemVanOnsem Thank you, you are correct. However my main issue is with users being authenticated while I would rather the request.user be None – Julian Sam Apr 11 '21 at 22:20
  • 1
    @DanYishai Here is why I want to disable it. If i do a login/signup operation from a source, then the following operations from that source will all have session middlewares that will authenticate the user, but I would rather the user be unauthenticated unless there is an Authorization header – Julian Sam Apr 11 '21 at 22:22
  • But no query is performed even if the session cookie is provided. You can also just logout after you finish working with the admin page, then you will not have that cookie anymore. – Dan Yishai Apr 11 '21 at 22:24
  • Another interesting idea is to move the admin page to another host using https://django-hosts.readthedocs.io/en/latest/, then the cookie will not be passed between the admin page and the primary page. – Dan Yishai Apr 11 '21 at 22:26
  • Changing hosts is not a bad idea.. I think then I can keep admin page logins seperate from the rest of the api. I will look into the documentation for this. – Julian Sam Apr 11 '21 at 22:32
  • 2
    I guess something else I've realized is that my overall flow of having a previously signed-in user then make other calls to the rest of the api (without calling signout) expecting the user to be annonymous not a proper flow, and I should rethink how that works.. – Julian Sam Apr 11 '21 at 22:34

0 Answers0