Idea: Allow session usage without Token model

[bufke]

Use case

Sometimes it's desirable to have a SPA that only uses session authentication. Sessions are very simple and work sufficiently well when the SPA is running all under one domain.

Problem

It's not obvious how to do this. The quickstart suggests enabling rest_framework.authtoken. There is a setting to use JWT authentication instead. But there is no obvious way to use sessions and only session.

Workaround

We can fake auth tokens with "no op" functions and classes.

REST_AUTH_TOKEN_MODEL = "utils.NoopModel"
REST_AUTH_TOKEN_CREATOR = "utils.noop_token_creator"

def noop_token_creator(token_model, user, serializer):
    return None


class NoopModel:
    pass

An alternative workaround is to enable auth token even though it isn't used. This can lead to problems such as this which are not obvious how to around. Custom logic around user models and login views must account for unnecessary token creation.

In either case, the workaround involves either going out of ones way to support tokens, which are then never used, or ensuring they get disabled at all times.

[iMerica]

I can see session support being helpful for people who are building hybrid SPA apps in Django - where Django serves an html template and that template includes some React/Vue. However this package is not built with that use case in mind.

This package is focused on stateless and decoupled client/server architectures based on REST. Using sessions would violate lots of architectural principles that underpin that.

[io-ma]

So I have the exact opposite problem :-D
I want to nuke sessions backend and CSRF completely and only use token backend. Is this doable?
I see sessions are used in the demo, and that confused me a bit. Do I only set REST_SESSION_LOGIN = False ?

[Aniket-Singla]

Yes @io-ma setting REST_SESSION_LOGIN = False, wont perform django's default session login and logout. I know its bit late to reply but maybe helpful for others having same question.

[okapies]

I also need the option to use the session-based authentication without generating a token.

Using sessions would violate lots of architectural principles that underpin that.

Could you give some examples of situation the session is undesirable? @iMerica

[haakenlid]

I can see session support being helpful for people who are building hybrid SPA apps in Django - where Django serves an html template and that template includes some React/Vue. However this package is not built with that use case in mind.

What's wrong with that use case? I would think it's quite common to want to use the Django admin site out of the box, but also enable session login with dj-rest-auth for a frontend built with a javascript framework. For any app that runs in a web browser, a login cookie works fine and is exactly as stateful or stateless as using rest_framework.authtoken.models.Token.

[iMerica]

I would think it's quite common to want to use the Django admin site out of the box, but also enable session login with dj-rest-auth for a frontend built with a javascript framework

The DJANGO_SETTINGS_MODULE is a powerful thing that can be harnessed to achieve exactly this. I personally run two different instances of the same app:

• My main public site - an SPA that communicates with DRF and authenticates via JWT.
• A separate admin instance with an DJANGO_SETTINGS_MODULE that points to a admin-specific installed apps and routes.

[iMerica]

This is in the latest release