Splitting Django authentication between public and internal interfaces
Intro
Probably the most used Django feature is the admin. It’s rated as the most useful feature according to the Annual Django Survey. It helps to bring content management up to speed and with some love and effort, we can build rich management platforms with it.
The challenge
Django admin has a single users table, single session management and a single set of roles (users, groups, permissions). Public facing apps often leave the /admin available to the world. This is still bearable, but it brings some overhead to assuring the authorization is done right. Of course, MFA helps a bit, but that’s not a silver bullet.
Some best practices recommend splitting the authentication between public and internal systems. Some companies may have policies requiring this separation, and there are cases where it makes sense to completely separate the public part of application from the internal one. Including user management and authorization. Good example are ecommerce platforms where minimizing risk of any accidental opportunity for the user to have their permissions elevated is very welcome.
Preparing the project
In many cases, we would just rely on is_superuser or is_staff to take care of accessing Django admin. But for this case, we will approach it like two different applications. One will be public and the other one will provide Django admin, an internal interface. We will use the same project, just with two deployments and configurations.
Setting up the project
cd ~/our/project_root
poetry init
poetry add Django
poetry run django-admin startproject split
cd split
poetry run ./manage.py startapp account
Preparing the settings
We need to edit the settings.py by placing a line somewhere on top (we can do it just after the imports)
ENVIRONMENT = os.getenv('ENVIRONMENT', 'public')
This will be used in the next step to define which configuration to use.
Next, we modify INSTALLED_APPS:
INSTALLED_APPS = [
# 'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'account',
]
Commenting out admin and adding the account one. Note the admin doesn’t have to be commented out, but there is no reason for it to be loaded in the public environment.
Adding account models
Next we need to add models into account app:
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager
from django.contrib.sessions.models import AbstractBaseSession, BaseSessionManager
from django.db import models
from django.utils import timezone
class SessionManager(BaseSessionManager):
use_in_migrations = True
class PublicSession(AbstractBaseSession):
class Meta(AbstractBaseSession.Meta):
db_table = "django_session_public"
objects = SessionManager()
@classmethod
def get_session_store_class(cls):
from .session import SessionStore
return SessionStore
class UserManager(BaseUserManager):
"""Define a model manager for User model with no username field."""
use_in_migrations = True
def _create_user(self, email, password, **extra_fields):
"""Create and save a new user with the given email and password."""
if not email:
raise ValueError('Email is required')
email = self.normalize_email(email)
user = self.model(email=email, **extra_fields)
user.set_password(password)
user.save(using=self._db)
return user
def create_user(self, email, password=None, **extra_fields):
"""Create and save a regular User instance with the given email and password."""
return self._create_user(email, password, **extra_fields)
class User(AbstractBaseUser):
USERNAME_FIELD = 'email'
REQUIRED_FIELDS = []
email = models.EmailField('Email Address', unique=True)
first_name = models.CharField(max_length=255, blank=True)
last_name = models.CharField(max_length=255, blank=True)
is_staff = models.BooleanField(default=False)
is_active = models.BooleanField(default=False)
is_superuser = models.BooleanField(default=False)
date_joined = models.DateTimeField(default=timezone.now)
date_activated = models.DateTimeField(null=True, blank=True)
objects = UserManager()
def __str__(self):
return self.email
Extending the settings
And then we add more settings to the end of settings.py:
if ENVIRONMENT == 'admin':
SECRET_KEY = 'f)@*$1$t(r(4@zzx14-$nf-g!9_(f)4y5(0ptl&77==tuv@1q0'
INSTALLED_APPS.append('django.contrib.admin')
elif ENVIRONMENT == 'public':
SECRET_KEY = '-cme0m8%$s32=xmo60k(l+mmhsln7wl!&l=6or3bgu^dw#86h2'
AUTH_USER_MODEL = 'account.User'
AUTHENTICATION_BACKENDS = ['account.backends.EmailBackend']
SESSION_ENGINE = "account.session"
SESSION_COOKIE_NAME = "sessionid_public"
else:
raise ValueError(f'Invalid environment: {ENVIRONMENT}')
The first condition loading django.contrib.admin for the admin environment. The second one is for the public environment. If the condition is met,
we load the custom auth model, custom email backend and custom session engine with dedicated table.
Adding the custom session engine
The session engine is a very simple override:
from django.contrib.sessions.backends.db import SessionStore as DBStore
from .models import PublicSession
class SessionStore(DBStore):
@classmethod
def get_model_class(cls):
return PublicSession
Email back end
This will make the email authentication work with the custom setup:
from typing import Optional
from django.contrib.auth import get_user_model
from django.contrib.auth.backends import ModelBackend
class EmailBackend(ModelBackend):
def authenticate(self, request, username: Optional[str] = None, password: Optional[str] = None, **kwargs):
if not username or not password:
return None
UserModel = get_user_model()
try:
user = UserModel.objects.get(email=username)
except UserModel.DoesNotExist:
return None
if user.check_password(password) and self.user_can_authenticate(user):
return user
return None
Migrations
First we will run the admin migrations (this will be run only once):
ENVIRONMENT=admin poetry run ./manage.py migrate
ENVIRONMENT=public poetry run ./manage.py makemigrations account
ENVIRONMENT=public poetry run ./manage.py migrate
The above migrates both the auth and account models.
Adding template and views
We edit the account/views.py file adding the following:
from django.contrib.auth import login, logout
from django.contrib.auth.forms import AuthenticationForm
from django.shortcuts import redirect, render
def demo_view(request):
if request.method == 'POST':
form = AuthenticationForm(request, data=request.POST)
if form.is_valid():
login(request, form.get_user())
return redirect('demo_view')
else:
form = AuthenticationForm() if not request.user.is_authenticated else None
context = {'form': form}
return render(request, 'account/demo.html', context)
def logout_view(request):
logout(request)
return redirect('demo_view')
For demo purposes, we only add demo view which will also serve as a login page and logout view. On POST request we try to login the user with provided credentials.
Otherwise we either display login form or no. The rest is processed in the following account/templates/account/demo.html template file:
{% block content %}
{% if user.is_authenticated %}
<p>Logged in as {{ user }}</p>
<form method="post" action="{% url 'logout_view' %}">
{% csrf_token %}
<button type="submit">Logout</button>
</form>
{% else %}
<form method="post">
{% csrf_token %}
{{ form.as_p }}
<button type="submit">Login</button>
</form>
{% endif %}
{% endblock %}
Finally the split/urls.py file:
from django.contrib import admin
from django.urls import path
from django.conf import settings
from account.views import demo_view, logout_view
urlpatterns = []
if settings.ENVIRONMENT == 'admin':
urlpatterns.append(path('admin/', admin.site.urls))
else:
urlpatterns.append(path('', demo_view, name='demo_view'))
urlpatterns.append(path('logout/', logout_view, name='logout_view'))
Testing the setup
Admin instance
Let’s create superuser account:
ENVIRONMENT=admin poetry run ./manage.py createsuperuser
Username: super
Email address: super@super.sup
Password:
Password (again):
Superuser created successfully.
We can now start the admin instance:
ENVIRONMENT=admin poetry run ./manage.py runserver 0.0.0.0:8880
Watching for file changes with StatReloader
Performing system checks...
System check identified no issues (0 silenced).
February 25, 2025 - 20:23:42
Django version 5.1.6, using settings 'split.settings'
Starting development server at http://0.0.0.0:8880/
Quit the server with CONTROL-C.
After opening http://localhost:8880/admin we should see the login form. We can login with user super and the password we set.
But we don’t have a way to add the public facing user, do we? Let’s extend the account app with in account/admin.py file:
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.forms import UserCreationForm, UserChangeForm
from .models import User
class AccountUserAdmin(UserAdmin):
form = UserChangeForm
add_form = UserCreationForm
list_display = (
'email', 'first_name', 'last_name', 'is_active', 'last_login')
list_filter = ('is_active', 'date_joined', 'date_activated', 'last_login')
fieldsets = (
(None, {'fields': ('email', 'password')}),
('Personal info', {'fields': ('first_name', 'last_name')}),
('Important dates', {'fields': ('last_login', 'date_joined', 'date_activated')}),
('Permissions', {'fields': ('is_active',)}),
)
add_fieldsets = (
(None, {
'classes': ('wide',),
'fields': ('email', 'first_name', 'last_name', 'password1', 'password2', 'is_active'),
}),
)
search_fields = ('email', 'first_name', 'last_name')
ordering = ('email',)
filter_horizontal = ()
admin.site.register(User, AccountUserAdmin)
After the dev server reloads and we refresh the admin site, we should see the new app with Users.
And we add a new user:
Once it is done, we can proceed.
Public instance
We start the public instance:
ENVIRONMENT=public poetry run ./manage.py runserver 0.0.0.0:8881
Watching for file changes with StatReloader
Performing system checks...
System check identified no issues (0 silenced).
February 25, 2025 - 20:38:09
Django version 5.1.6, using settings 'split.settings'
Starting development server at http://0.0.0.0:8881/
Quit the server with CONTROL-C.
And we check http://localhost:8881/. We should see the login form
And then:
Limitations / Constraints / Considerations
We can check that we have two sets of session keys
This name differentiation is not required because the two interfaces will sit on two different subdomains/domains/whatever. It is for demo purposes and in this demo case it helps us to be logged in as both users in both urls on localhost within the same browser. What won’t work however is the csrf token. It will work in two browsers or in two subdomains/domains though (or you will have to remember refresh the other tab after you’ve done something in the first one).
In the PublicSession we inherit from AbstractBaseSession and not from Session (what would be easier). This we do to really split auth completely. If we inherited from Session the approach would still work, but the new table would only reference the primary django_session and that would mean the session ids would be stored in the table used for admin interface. In such a case if we had two users (one admin one public) with the same user id and if we used single SECRET_KEY, the session store would be then possibly pointing to an id of super user. The overall risk would be close to zero, but let’s rather have it this way. Anyways, having two SECRET_KEY values means, if we attempted cross-access between session keys, we would receive Session data corrupted error.
There could be some corner cases where the SessionStore is imported from django.contrib.sessions.backends.db and not account.session. This shouldn’t be a problem
for most cases. But in case we plan to work with the direct imports somewhere, we have to take this into account.
Outro
This is one of the options how to approach complete separation of users between the internal management and public facing app. One of the limitations of this approach is that we completely skipped groups and permissions. In case you want to use the built-in RBAC, this solution won’t work for you as is.
Please take this as a part of puzzle which you can build on top of. But you still need to approach it with caution as any work related to authentication and authorization.
You can find the complete example in Github