22.12 The portal's own pages
- Approved by
- Panaversity ·
In everyday life. A dry cleaner gives you a numbered ticket for your coat. When you come back, the clerk checks the ticket against the name on the order, because anyone could read a number off a ticket left on a counter. A request to release your coat counts only on the shop's own stamped slip, not on a letter someone else sent in your name. And a note pinned to your coat by a stranger is read as a note. The clerk does not follow its instructions. In this concept, the ticket is a session id, the stamped slip is a form token, and the pinned note is text a stranger put into a session.
What you will learn. Two rules for the portal's own web pages: who may see or change a run, and why nothing a run returns is ever treated as page code.
Why it matters. A web site can leak in ways a server cannot. Without these rules, anyone who learns a run's id could watch it, and a stranger's note could act as the person reading it.
Which four web words does this concept use?
The portal is a web site, and web sites have their own ways to leak.
- A cookie is a small value the browser keeps for a site and sends back with every request. The portal's sign-in cookie says who is signed in.
- A form token is a one-time value the portal puts into its own page, and checks when the page sends something back. Another web site cannot know it.
- A script is code inside a web page that the browser runs.
- A content security policy is a rule the portal sends with its pages: "run only the scripts I shipped, nothing else."
One request, start to finish. Ana has heard the id of Luis's session from a colleague. She types it into the portal's address bar to watch his events. And at the same time, Cedar Ridge's vendor V102 has a note in its record that contains a piece of web page code, a script.
- The portal receives Ana's request for that session's events.
- It looks up its own record of who started the session: Luis, at Cedar Ridge.
- It refuses, because the signed-in person is Ana. She sees "not found", which tells her nothing about whether the session exists.
- That evening, Luis opens a web page from a stranger. Hidden in it is a request to the portal: "approve the waiting tool call in Luis's session". His browser would send his cookie with it, so it looks as if Luis sent it. The portal refuses it, because the request carries no form token, the portal's own stamp, from the portal's own page.
- Later, Luis asks about V102. The worker's answer quotes the vendor note, script and all.
- The portal shows the note as plain text. The script appears as characters on the screen. It never runs.
Nothing about the session's id, or the text inside it, gave anyone more than the signed-in person already had.
What are the two page rules?
Two rules use those four words:
- A session belongs to the person who started it. The portal records each session it starts, with its person, company and vault. Every later request about that session, to stream its events, answer a confirmation or interrupt it, is checked against that record. The requests that change something also need a form token from the portal's own page. Without the first check, Ana could watch or approve Luis's work by guessing an id. Without the second, another web site Ana visits could make her browser send those requests for her, using her cookie.
- Nothing from a session is trusted by the page. Model answers, tool inputs and tool results can carry text a stranger wrote, such as a vendor note. The portal shows all of it as plain text, never as web page code, and its content security policy forbids running any script it did not ship. Otherwise a note containing a script could run in Ana's browser and act as her.
At work. In Lab 22, Task 10c, Claude Code builds the portal's session pages with both rules. In Task 12, the session matrix tests them: row S8 asks for Luis's session as Ana, and row S7 shows a vendor note holding a script and checks that it appears as plain text.
Which rows of the session matrix prove these rules?
Rows S7 and S8 of 22.11's table prove this concept's rules. S7 checks that no sign-in token appears in any event, and that nothing from a session runs in the page. S8 checks that a session belongs to the person who started it.
The operating rule: check every request about a session against the person who started it. Show everything from a session as plain text.

Figure 22.18. Two page rules: a session belongs to its owner, and nothing from it runs in the page.
Part C in one minute
Three identities, never one: your product, the worker, and the person it acts for (22.9). Each person's token lives in their own vault, where the model never sees it (22.10). Your server, never the page or the model, picks exactly one vault per session, and a test proves every rule (22.11). And the portal's pages show only a person's own sessions, as plain text (22.12).
Now do Lab 22, Sitting 3a on the lab page: Tasks 9 to 11 (about 2 hours 45 minutes). It ends Milestone 1. Then come back for Part D, when you are ready to make the worker safe to sell.
Check yourself
Question 1 / 8
0 answered
Ana pastes the id of Luis's session into the portal and asks to stream its events. What should happen?
- Owner
- Panaversity