Architecture

Four apps, one identity provider.

CampusHub is four independent Django projects — FacultyHub, PeopleHub, ChemTrack and AuthHub — each with its own database and Docker container, sharing one nginx gateway and one login. This page covers how they fit together, and every route each one exposes.

The four apps

FacultyHub

/facultyhub/

Lab bookings, safety inductions, equipment directory, helpdesk, internal messaging, fieldwork tracking, and analytics. The largest of the four apps — 18 Django apps in one project.

— routes

PeopleHub

/peoplehub/

Campus activity map, incident and event tracking, security patrol routes with checkpoints, and a staff directory.

— routes

ChemTrack

/chemtrack/

Chemical inventory tracking — hazard-aware storage locations, QR-coded containers, usage logs, and an approvals queue for controlled substances.

— routes

AuthHub

/auth/

The shared sign-on the other three apps redirect to. Issues a short-lived signed token; each app verifies it and either logs the user in or provisions a minimal account.

— routes

How sign-on works

A visitor without a session is redirected to /auth/login/. On success, AuthHub signs a short-lived token (30-second expiry) carrying the user's email, the requesting app, and a random nonce, and redirects back to the app that sent them with ?sso_token=… appended. Each app's provisioning middleware verifies that token against a signing key shared across all four apps' .env files, checks the nonce hasn't been used before (closing the replay window an email-only token would leave open), logs the user in (or creates a minimal local account on first sign-in), then redirects again to strip the token from the URL. The token format and nonce handling live in one shared campushub_sso package so the four apps can't drift out of sync. The four apps don't call each other at request time otherwise — no shared session store, no shared database. AuthHub only proves identity; each app still applies its own role/permission model on top.

AuthHub separately exposes a standards-based OAuth2/OIDC provider at /auth/o/ — authorization code + PKCE, discovery document, JWKS, UserInfo — for any external, OIDC-native client. It runs fully in parallel to the sign-on flow above, with its own signing key and no shared code: the other three apps keep using the HMAC token scheme as before.

Sitemap

Every route exposed by the four apps, grouped by Django app under each namespace. Generated directly from each app's URLconf — see scripts/generate_sitemap.py in the repo — so it can't drift out of date the way hand-written docs do. Click a namespace to expand its individual routes.

Loading sitemap-data.json…