22.11 One session, one person, one company

In everyday life. A bank teller serves one customer at a time. She asks for the customer's card, not the customer's word, before she opens an account on her screen. She closes it before the next customer steps up. And the bank checks her work by sending a test customer through now and then, with the wrong card, to see if she notices. In this concept, the teller is the portal's server, the card is the sign-in, and the test customer is the session matrix.

What you will learn. How the portal's server chooses which person's vault each run carries, the rules that keep one person's run away from another's, and how a test proves each rule.

Why it matters. A question, a page or the model could name any company. If anything but the signed-in person chooses the vault, Luis's question can run with Ana's rights.

One request, start to finish. Luis at Cedar Ridge asks: "Who is vendor V001, and what do we owe them?" Brightline also has a vendor V001, a different company.

The portal's server reads who is signed in from its own sign-in cookie: Luis, Cedar Ridge.
It looks up the one vault for Luis at Cedar Ridge in its table.
It starts a session naming that vault, and only that vault, and a budget.
The worker calls find_vendor for V001. The platform adds Luis's token. The connector reads the token's tenant claim, Cedar Ridge, and the database's row-level security (Chapter 19) shows only Cedar Ridge's V001.
Luis gets Treasure Valley Lumber, Cedar Ridge's V001, and Cedar Ridge's own total.

Nothing in the question, the page or the model chose the company. The signed-in person did.

Where could two companies meet now?

Chapter 18 kept companies apart at sign-in, and Chapter 19 kept them apart in the database. A hosted worker adds a new place where they could meet: the session. A few rules close it, and each is proved by a test that fails if the rule is broken.

Figure 22.16. The server chooses the vault, one step at a time. Nothing the page or the question says can change it.

What is a grant?

When a person approves consent, the sign-in server records a grant: their standing permission for the portal to get tokens for them, until it is withdrawn. Chapter 18 called this record a consent record, and used "grant" for a way of getting a token. Removing a person from a company withdraws it.

What is the session matrix?

You build it in Milestone 2 (Task 12). For Milestone 1, read the rule column and skim the rest. Chapter 18's sign-in matrix asked "can one company act as another?" Chapter 19's data matrix asked "can one company's rows reach another?" The session matrix asks the next question: can one person's or company's session reach another's? Each row proves one rule, except S7, which proves both of 22.12's page rules. In Milestone 2 you also plant a bug for each row, to show the row really fails when its rule is broken. That table is at the start of Sitting 3b.

Row	The rule	Why it matters
S1	The server picks the vault from the signed-in person, never from the browser, the question or the model	A question could say anything
S2	A vault id from the browser is ignored	A page could send any vault id
S3	Exactly one vault per connector per session	With two vaults for the same connector address, the platform uses the first, so Luis's session could act as Ana
S4	No company in the definition. The company comes only from the token	One definition serves every session
S5	A removed person cannot start a session, because the portal first asks the sign-in server whether the person is still a member, and their vault is archived	Leaving a company must end access. Removal also withdraws the person's grant
S6	An offboarded company's vaults are archived, and its scheduled runs pause	No future session can use them
S7	Explained in 22.12. No sign-in token in any event, and nothing from a session runs in the page (22.12)	A token in a page or a log can be stolen
S8	Explained in 22.12. A session belongs to the person who started it (22.12)	Anyone who learns a session id could watch it

Rows S7 and S8 are about the portal's own pages, which the next concept, 22.12, explains. Read them now as names only.

Which rules have no row of their own?

The application is the boundary. The platform does not know which of your users owns which vault, so your server checks every time. Rows S1 to S3 together prove it.
The connector and the database still check. The session rules are a new lock, not a replacement for the old ones. Chapters 18 and 19's tests still run in CI.
Scheduled runs are checked for removed people, because a scheduled run does not pass through the portal's session start. That rule belongs to Milestone 2, so 22.15 covers it.

At work. In Lab 22, Task 12, OpenCode writes scripts/session-matrix.ts and runs it in staging: eight rows, each starting real sessions that cost a few cents. In Task 12b, it plants each bug in turn, on a branch, runs the matrix rows that bug targets and the configuration check, records the result in ports/ch22.md, and deletes the branch. Every bug must fail at least one row.

The operating rule: choose one vault per session on the server, from the signed-in person and their current membership. Prove each rule with a test that fails when it is broken.

Figure 22.17. The session matrix, and the trap behind row S3: with two matching vaults, the first one wins.