Admin Interface & Settings

Django Fundamentals — Admin Interface & Settings
Django Fundamentals
Course 1 · Chapter 8 · Admin Interface & Settings

🛠️ Admin Interface & Settings

Neither FastAPI nor Express gives you this for free: a full CRUD interface for every model, generated automatically, with authentication already built in. This final chapter turns on Django's admin site for the models built across this course, then ties together settings.py — the file this course has referenced loosely in nearly every chapter without ever looking at directly.

Creating a Superuser

The admin site needs an account with full access — createsuperuser is an interactive command that sets one up:

python manage.py createsuperuser # Username: admin # Email address: admin@example.com # Password: ******** # Password (again): ******** # Superuser created successfully. python manage.py runserver # Visit http://127.0.0.1:8000/admin/ and log in.

📋 Registering Models

A model appears in the admin the moment it's registered — one line, versus building an entire CRUD UI by hand:

# catalog/admin.py from django.contrib import admin from .models import Book, Author, Tag, Publisher admin.site.register(Book) admin.site.register(Author) admin.site.register(Tag) admin.site.register(Publisher)

Hand-Building CRUD vs Django's Admin

FastAPI / Express: Build It Yourself

Routes for list/create/edit/delete, HTML templates for each, form handling, pagination, search, access control for who can reach these pages — all written and maintained by hand, per model.

Django: Four Lines

admin.site.register(Book) — full list view, create/edit forms (auto-generated from the model's fields), delete confirmation, search, and login-gated access, all included.

Customizing With ModelAdmin

The default registration works, but a ModelAdmin subclass controls exactly what the list view shows and how it's searched/filtered:

from django.contrib import admin from .models import Book, Author @admin.register(Book) class BookAdmin(admin.ModelAdmin): list_display = ["title", "author", "price", "in_stock"] list_filter = ["in_stock", "author"] search_fields = ["title", "author__name"]

list_display

Which columns appear in the list view — without it, the admin shows only each row's __str__.

list_filter

Adds a sidebar of clickable filters — Django generates the filter options from the field's actual values automatically.

search_fields

Enables a search box; "author__name" reaches across the relationship the same way a QuerySet filter would (Chapter 6).

@admin.register(...)

A decorator form equivalent to calling admin.site.register(Book, BookAdmin) separately — just a more compact way to associate a model with its customization class.

Inline Editing: Related Models on One Page

An Inline lets you edit an author's books directly on the author's own admin page — no separate navigation needed:

Editing Books Inline on the Author Page

from django.contrib import admin from .models import Author, Book class BookInline(admin.TabularInline): model = Book extra = 1 # how many empty "add a new one" rows to show @admin.register(Author) class AuthorAdmin(admin.ModelAdmin): list_display = ["name"] inlines = [BookInline]

⚙️ Tying It Together: settings.py

Every chapter has referenced settings.py loosely — here's the same file, with everything covered so far pointed out in context:

# mysite/settings.py DEBUG = True # see this chapter's gotcha below ALLOWED_HOSTS = [] # hostnames allowed to serve this site in production INSTALLED_APPS = [ # Chapter 1 — an app does nothing until it's listed here "django.contrib.admin", # powers this very chapter's admin site "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.messages", "django.contrib.staticfiles", "catalog", ] MIDDLEWARE = [ # Chapter 7 — CsrfViewMiddleware lives in this list "django.middleware.security.SecurityMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", "django.middleware.csrf.CsrfViewMiddleware", "django.contrib.auth.middleware.AuthenticationMiddleware", "django.contrib.messages.middleware.MessageMiddleware", ] TEMPLATES = [{ # Chapter 4 — where DTL looks for app-level templates/ directories "BACKEND": "django.template.backends.django.DjangoTemplates", "APP_DIRS": True, }] DATABASES = { # Chapter 5 — the connection every QuerySet ultimately runs against "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", } }

💻 Coding Challenges

Challenge 1: Register and Customize a Model

Register the Tag model (Chapter 6) with a TagAdmin that shows name in list_display and enables searching by name.

Goal: Practice the @admin.register + ModelAdmin customization pattern on a model not already covered in this chapter's examples.

→ Solution

Challenge 2: Add an Inline

Add a PublisherAdmin with a BookInline so a publisher's books can be added/edited directly from the publisher's own admin page, matching the AuthorAdmin pattern from this chapter.

Goal: Practice reusing the same TabularInline pattern for a different relationship.

→ Solution

Challenge 3: Audit a Production settings.py

Given a settings.py with DEBUG = True and ALLOWED_HOSTS = [] deployed to a real production server, explain what's wrong with each setting and what the corrected values should look like.

Goal: Practice recognizing the specific security misconfiguration this chapter's gotcha (and the OWASP course's Security Misconfiguration chapter) warns about.

→ Solution

⚠️ Gotcha: DEBUG = True in Production

Django's debug page is genuinely excellent for local development — full stack traces, every local variable's value, the entire request. It is also a severe security exposure if left on in production: an unhandled error on a live site would hand any visitor a detailed view of your source code, settings (including secret keys, unless carefully filtered), and internal application structure. This is precisely the "verbose errors" misconfiguration the OWASP Top 10 course's Security Misconfiguration chapter covered — DEBUG must be False in production, with ALLOWED_HOSTS set to the real domain(s) the site serves (Django refuses to serve requests to unrecognized hosts specifically to prevent HTTP Host header attacks).

🎓 Course Complete

That closes Django Fundamentals. Across eight chapters, one contrast ran throughout: where FastAPI and Express hand you a thin core and let you assemble the rest, Django starts from a fully furnished house — routing, an ORM, a templating engine, forms with built-in CSRF protection, and now an entire admin interface, all included from django-admin startproject onward. Course 2 (Intermediate/Advanced) — authentication, Django REST Framework, testing, Celery, caching, and deployment — is sketched and ready in the course bucket list whenever you want to continue.