Roles in the app

In 1 minute

Every user has a role: user or admin. RBAC (role-based access control) means a route checks the role, not the person. Creating an event uses adminProcedure: a missing session or deleted account gives 401; an existing non-admin user gives 403. Each admin authorization check reads Postgres, so a role change does not wait for a cached session role to expire.

Picture it

flowchart TB
  R["events.create"] --> A{"session?"}
  A -->|"no"| E401["401 UNAUTHORIZED"]
  A -->|"yes"| B{"role lookup in Postgres"}
  B -->|"account missing"| E401
  B -->|"user"| E403["403 FORBIDDEN"]
  B -->|"admin"| OK["create the event"]
  B -->|"lookup failed"| E500["500 INTERNAL_SERVER_ERROR"]

How it works

1. Three kinds of procedure. publicProcedure lets anyone in. protectedProcedure adds the session check. adminProcedure adds the role check on top.
2. 401 first. isAuthed throws UNAUTHORIZED when there is no session: “we do not know who you are”.
3. Then the role. isAdmin looks up the role by user id. A missing user gives 401. A user role gives 403 FORBIDDEN: “we know who you are, and you may not do this”.
4. Fail closed. If the role lookup fails (Postgres down), the request fails. We never let someone through when we cannot tell.

In MiniTickets

The middleware lives in apps/api/src/trpc/init.ts → adminProcedure. events.create is an admin route; browsing events is public; booking is protected.

The role column has a default of user and a database CHECK that allows only user or admin, so even a typo from a script is refused (apps/api/src/db/schema/users.ts).

There is no screen for roles, on purpose. The make-admin script changes the role in Postgres and revokes the user’s sessions, so they must log in again (apps/api/src/scripts/make-admin.ts).

Hiding the admin link in the web app is only for looks; the API check is the real one.

See the API app on the map →

See it in AWS

Console

Roles live in Postgres, not in AWS IAM. The API log shows 401 and 403 answers with their correlation ids.

CLI

aws logs tail /minitickets/dev/api --since 10m --filter-pattern FORBIDDEN

Code

apps/api/src/trpc/init.ts → isAdmin

Break it

Symptom	Cause	Where to look
A new admin still gets 403 after logging in again	The role change went to the wrong email	The users row
An admin page loads, but saving gives 403	The UI shows the page; the API checks the role	Working as designed
Admin routes return 500 while the cached events list works	Postgres is down; the role check fails closed	/ready, the API log

Say it in an interview

Say it like this (20-30 seconds)

Authorization is middleware on tRPC procedures. adminProcedure is protectedProcedure plus an isAdmin check: no session or a deleted account is 401, an existing non-admin user is 403. Each check reads Postgres, so role changes affect new checks without waiting for session expiry. Requests already authorized can still finish. A lookup failure fails closed with 500. Frontend checks guide users; the API enforces access.

Follow-ups

Why not store the role in the session?

Without revocation or another refresh mechanism, a copy could stay old until the session expires after 7 days. Reading Postgres avoids that stale role. The trade-off is one primary-key lookup per admin check and a dependency on database availability.

Why not look up the role in createContext for every request?

Then every route, even the public events list, would depend on Postgres for something only admin routes need. With Postgres down, a logged-in visitor could not browse cached events.

What is the difference between 401 and 403?

401: not authenticated, logging in may help. 403: authenticated but not allowed, logging in again will not help.

Advanced: Why make-admin revokes sessions

The service revokes sessions before updating Postgres and again afterward. The second revocation removes sessions created by concurrent logins before that point. This is not one atomic change across Postgres and Valkey: a login can save a session after the second revocation, and a request already authorized can finish. Reading the role on each new check still prevents a stale session role from preserving admin access.

Checkpoint

Answer these without scrolling up. If one feels hard, reread that section.

1. Which three procedure kinds exist, and how do they build on each other?
2. When does the API answer 401, and when 403?
3. Why is the role read from Postgres on each admin request?
4. What protects the role column from a typo?
5. Why is hiding the admin link not security?

Redraw it from memory: the decision: session? then role = admin? with the 401, 403 and OK outcomes

Try this: on the local stack, call events.create logged out and then as a normal user, and compare the two error codes

Mark this page as read