Multi-tenant application: organization-scoped routes in Axum

Description and use

Featherboard implemented path‑based organization scoping with a CurrentOrg extractor, enforced org_id checks in SQL, and added comprehensive tests to ensure tenant isolation.

Problem

Ensuring that an organization identifier is consistently carried through and validated across all requests in a multi‑tenant Rust web application.

Outcome

Featherboard now reliably isolates data per organization, preventing accidental cross‑tenant access and simplifying hosting by using path‑based tenancy.

Workflow

• Define routes with /{org-slug}/… prefix.
• Create CurrentOrg extractor to parse slug and load org from DB.
• Inject CurrentOrg into handlers as a parameter.
• Add org_id condition to all SELECT, UPDATE, and authorization queries.
• Update HTML links, form actions, redirects, email links, Stripe checkout, and webhooks to include org slug.
• Write unit and integration tests to verify routing, access control, and redirect preservation.
• Deploy with path‑based tenancy to avoid wildcard DNS.
• Monitor for cross‑tenant access errors.

Evidence

Multi‑tenancy sounds like a simple idea - reuse the same application across multiple organizations. Usually, you put the organization identifier somewhere in the URL, like a subdomain or a path parameter.

Source

Instead of extracting the organization from the slug in every request, Featherboard implemented a CurrentOrg request extractor. It takes the path, extracts the first parameter, looks up the organization in the database, and provides the organization struct to the request handler.

Source

Organization scope is enforced in the resource query, not just through a route lookup.

Source

All of the above are quite fragile, because the compiler will not help you validate them. Rendering a website with invalid links still produces valid HTML, so writing proper unit tests and integration tests is absolutely essential.

Source