Authentication

This set of pages describes how JodApp Web, the React Router application in jodapp-web, knows who is signed in and what that person may open.

• It covers the two runtimes, the browser and the Node server, and what each one may do.
• It covers reading the session, changing it, the policy routes that guard areas, the rules they run, and where Rails draws the line.
• It describes the system as designed.
• The Rails side is in the Rails authentication pages. Both sets follow the same people, Mei and Ken, on the same days.
• The reasons behind each choice are on the JodApp Web decisions page, and the session design itself is Identities D5 — Server-side sessions replace jwt_sessions.

The pages, in reading order

1. What JodApp Web knows about a session: the two runtimes, the two paths to Rails, the cookie jar, and the three rules every later page relies on.
2. Reading the session: how the routes nest, the one read per request on Node, where the session is kept, and when React Router reads it again.
3. Changing a session: login, logout, sign out everywhere, the CSRF header, and what each refused response means.
4. Policy routes: the route tree, where a policy sits, what a policy route is made of, and the ten policies.
5. The policy loader: why every policy exports a loader, when it is requested, and the three edits that switch a policy off.
6. Entry rules: the lookup page, with the answer for every state and the redirect_to check.
7. Rails is the boundary: what Rails must enforce on its own, where page data loads, and why a stale copy in the browser is safe.
8. A worked example: four moments as sequence diagrams.
9. Where the code lives: one table of files, grouped the way the pages are.

Three rules that hold on every page

1. No cookie means no call.
   • A request to Node with no session cookie is treated as signed out, and Node never calls Rails for it.
2. Only 401 means signed out.
   • A 403, a 5xx and a network failure are errors. They change nothing about the session.
3. Neither runtime judges a session.
   • JodApp Web never reads a cookie's age, never refreshes anything, never retries a refused request, and never navigates or clears state because one call was refused.
   • It sends the cookie and acts on Rails's answer. Rails decides, on every request.