December 2022 Summaries

Using a Rust Axum endpoint that authenticates a user and saves a URL as a practical example, the post demonstrates how iterative refactoring can turn a crowded route handler into a concise, reusable design. It moves authentication-header extraction and verification into a custom `FromRequestParts` implementation for `User`, allowing protected routes to declare a `User` parameter instead of repeating authorization logic, while noting that body-consuming extractors such as JSON must appear last. It then replaces explicit database-result matching with Rust’s `?` operator by introducing an application error type that converts database errors and implements `IntoResponse` to produce HTTP error responses. Finally, the SQL operation is moved into a database-layer method, leaving the route responsible for coordinating request data, authentication, persistence, and its route-specific response. The resulting structure improves readability, reuse across future routes, and separation of concerns, though the post notes that explicit error handling may still be preferable when a route must distinguish among several failure cases.

PropelAuth has released a Rust crate for adding authentication and authorization to backend applications, reflecting the company’s own use of Rust for much of its infrastructure. The crate includes integrations for Actix and Axum, alongside a framework-independent library, and allows developers to protect API routes by automatically requiring valid access tokens. Designed for B2B and multi-tenant products, it supports validating organization membership as well as user roles and permissions, returning authorization errors when requirements are unmet. It also provides API functionality for tasks such as creating users, retrieving organization members, and generating magic links, with support available through PropelAuth’s support channel.

PropelAuth is presented as an authentication and authorization service for B2B, multi-tenant applications, illustrated through a restaurant SaaS product where owners, managers, and frontline employees require different access levels across one or more restaurants. Its organization feature can be relabeled as “Restaurant” and supplies configurable interfaces for creating organizations, inviting members, and assigning roles. In React and Next.js applications, the `useActiveOrg` hook and `getActiveOrgFn` can identify the restaurant currently being viewed through URL paths or subdomains while verifying that the logged-in user belongs to it. `RequiredAuthProvider` manages authentication data and redirects unauthenticated users to login, while `withRequiredAuthInfo` provides user and access information to components. Roles and permissions can then control both member management and interface visibility, such as showing billing navigation only to owners through the `accessHelper`, although backend APIs must still independently enforce authorization for security.