Module 50: Full-Stack Integration
Sign-in, roles and permissions across the stack
🏠The everyday picture
An office where the reception desk, the lift and every door use the same staff card system. Your card works everywhere you're allowed and nowhere else, and losing it can be cancelled in one place.
📘What it really is
-
Sign-in flow: the login form posts to
/v1/sessions; the API sets the session cookie; the frontend calls/v1/meto learn who's signed in and their role, and keeps that in its auth context (Module 37). -
On load: call
/v1/me. If it returns 401, show the login page. If the session expires later, any 401 from the API sends the person to sign in again and back (Modules 36 and 38). -
Roles in the UI: show only the actions a person can take ("Delete" for admins), using the role from
/me. This is for clarity only. -
Roles on the server: every rule enforced by the API (Module 48), with tests. If the UI and API ever disagree, the API wins, and the UI shows its 403 message gracefully.
-
Sign-out:
DELETE /v1/sessions/current, clear the cached data (TanStack Query'squeryClient.clear()), and return to login, so the next person on a shared computer sees nothing. -
Test both roles: sign in as staff and as admin, and try every action as each.
🖱️Try it
Connect sign-in, /me, sign-out and session expiry between the React app and the API. Show admin-only actions only to
admins. Then, signed in as staff, use developer tools to send an admin-only request directly (copy a request as
fetch and change it) and check the API refuses it with 403.
✅Quick check
Why clear cached data on sign-out?
Show the answer
So the next person using the same browser can't see the previous person's data.
The UI hides "Delete" from staff. Is that enough?
Show the answer
No. The API must refuse deletes from staff; hiding the button is only for clarity.