A worked example

Four moments, each as one picture. Mei is a talent on her laptop. Ken is an employer. The ids match the Rails worked example, which follows the same days from the Rails side.

• Each picture shows the browser, Node and Rails, and which of them does what.
• Under each picture, three things to notice and nothing more.
• This page covers four moments.
  • Mei signs in, and the first read that follows.
  • Mei clicks inside the app, and two requests leave together.
  • Mei's cookie outlives her session.
  • Ken's company is disabled while he is signed in.

The words this page uses

Word	Meaning
.data request	The browser asks Node for route data only, on a click inside the app. It happens only when a matched route exports a loader, which every policy route does. The policy loader page explains why
The getter	getIdentitiesUserSessionsCurrent(), the function the root middleware puts in router context. The first caller starts the one request to Rails. The reading-the-session page shows it
Policy	A policy route: the route that decides whether the routes inside it may open, with one entry rule. The policy routes page lists all ten, and the entry rules page holds every rule's table
clientAction	The route export that runs in the browser when a form submits. Every session change is one. The changing-a-session page explains it

Mei signs in, and the first read that follows

Monday 09:01. Mei is on /login, signed out, and clicks "Sign in".

What to notice:

• The write goes straight from the browser to Rails. The read that follows goes through Node.
• The action reads nothing from the login response. The cookies are the change, and the reload reads the truth.
• Node called Rails once, from the root loader, because no policy sits on /.

Mei clicks inside the app, and two requests leave together

09:25. Mei is on the home page, /, and clicks "My applications". That click enters talent-required-policy.

What to notice:

• One click, two requests to Rails, one from each runtime, both with the same cookie. The policy ran because this click entered its area. A click between two pages inside the area would send nothing to Node.
• They leave together because React Router starts every matched route's loading at once, and sends the .data request only after all of them have started. The .data request exists only because the policy exports a loader. The policy loader page shows the source.
• Rails checked both requests on its own. The policy shaped the journey, and Rails decided access.

Mei's cookie outlives her session

Mei did not open Jod for ten days. On day 8 Rails deleted Identities::UserSession 4021, because the idle limit is 7 days. Her cookie lives 30 days, so it is still in the browser. She opens /talent/profile in a new tab.

What to notice:

• Nothing in JodApp Web judged the cookie's age. Node forwarded it, and Rails was the only part that knew the session was gone.
• The 401 became null in the getter, a path in the rule, and a redirect in the guard. No code retried, navigated by hand, or cleared anything.
• redirect_to carried her destination through the login, and the safe-redirect check ran before it was used.

Ken's company is disabled while he is signed in

14:00. Ken is editing a job on the dashboard. An admin on the Team Portal disables his company. At 14:02 he clicks "Save".

What to notice:

• The stale active in Ken's browser granted nothing. Rails read the database at the moment of the save.
• One 403 with an access code was enough. The root route reloaded the session, and the policies did the rest.
• Ken was never signed out and never sent to create an account. A 403 never means signed out, and his account exists.