Admin, Accounts and Progress

Until now every visitor is anonymous and nothing on the site can be changed through the site itself. This chapter adds three small things: an admin for looking at what was imported, an optional login, and a button that remembers which chapters you have finished. The interesting part is not the code, which is short, but the decisions about what not to allow.

Who Is Allowed to Do What

The Admin: Its Own Host, Read-Only

Django's admin is the quickest way to see what is in the database, but two decisions matter more than the setup:

1. It has its own host. admin.osztromok.com (and admin.localhost in development) has its own URL configuration containing the admin and nothing else. The content sites do not contain the admin at all, so /admin/ is a plain 404 on every one of them: there is nothing to find or guess at. The middleware from Chapter 2 gained one branch: if the host is the admin host, use the admin's URL configuration.
2. It is read-only. The files are the source of truth and the importer overwrites the database from them, so a title edited in the admin would silently vanish at the next import. A form that loses your work without telling you is worse than no form, so the add, change and delete permissions are switched off for pages, courses and progress.

The page body is left out of the list (the query defers it) and out of the detail form, so listing 4,408 pages stays cheap. On the real database:

Times come from Django's test client, so they leave out the network. The tests also check that an ordinary user and a staff user with no permissions are turned away, and that a posted change and a posted delete leave the page unchanged.

Accounts: Optional, and Per Site

Nobody needs an account to read anything. A login only lets a site remember what you have finished. There is no public sign-up: the owner makes users in the admin, so there is no registration form to attack or to fill with spam.

• One login per site. The session cookie has no Domain, so a browser sends it to the host that set it and no other. Logging in on the languages site does not log you in on the systems site. Sharing a login would need SESSION_COOKIE_DOMAIN=".osztromok.com", which also hands the cookie to every subdomain you create later; the project keeps them apart. (The test client has one cookie jar for all hosts, so the test checks the cookie has no Domain instead of trying to see the separation.)
• The cookie is HttpOnly and SameSite=Lax (Django's defaults), and Secure in production. A login lasts 30 days.
• ?next= cannot send you elsewhere. Django follows it only when it points at the same host. Tested with https://evil.example/, //evil.example/ and another of the sites: each goes to /.
• Logging out is a POST with the CSRF token, so a link or an image on another page cannot do it.

Limiting Wrong Passwords

Django does not limit login attempts by itself. After 5 wrong passwords for one user name, the login answers 429 for 15 minutes, even to the right password. The count is kept for the name as typed, whether or not that name exists, so the reply never reveals which names are real. Three costs are worth knowing:

Progress

A logged-in reader sees a button at the bottom of every page: Mark as finished, or, once done, Mark as not finished. The /progress/ page lists each course on the site with how many chapters are finished. On the real content, five chapters of Hungarian Basic Conversation 3 marked finished gave “5 chapters finished” and “5 of 12” in 13 ms, and chapter 8 of the same course still showed the unfinished button.

Path, Not Foreign Key

A progress row stores the page's path (hungary/x/c1.html), not a link to the page row. The importer may delete and recreate a page, and a foreign key with the usual cascade would delete the reader's progress with it. With a path, a test deletes a page, recreates it and finds the progress still there. The cost is the other direction: if a file is renamed, its progress points at a path that no longer exists and counts for nothing. Renaming a chapter file is rare; losing progress on every re-import would not be.

The Safety Checks, Each With a Test

The redirect after marking is built from the page that was found, not from anything the visitor sent, so there is nothing to turn into an open redirect. The cached menus are unaffected, because nothing user-specific is cached. The page itself now differs for each logged-in reader, so a page that shows the button must never be cached as a whole.

Hands-On Exercises