WebSockets

02The handshake is not the edit

The worked edit names sender A and owner A, so it satisfies the edit rule. The activity changes the action to read. Notice the evidence limit: an edit-only rule does not establish a read policy. You can identify the sender, action and owner, but should not invent permission for an action the policy does not define.

Validate the handshake's origin and session as appropriate, then authorize and validate later messages. Session expiry can matter after the connection starts. These are separate checks at different boundaries. The printed handshake omits protocol details and is not a complete request to transmit or evidence of an observed socket connection.

03Decide the activity message

Read the evidence before comparing with the activity rubric. Do not open a socket.

Teaching model of a connection start. Not a captured handshake.
This card does not depend on a status number.

Request shape
GET /notes
Host: 127.0.0.1:8000
Upgrade: websocket
Connection: Upgrade

Response shape
the server accepts the upgrade

After acceptance, the connection carries messages.
The acceptance does not grant every later message.

{
  "rule": "A may edit only notes whose owner is A",
  "worked": {"from": "A", "action": "edit", "note": 7, "owner": "A"},
  "activity": {"from": "A", "action": "read", "note": 7, "owner": "A"}
}

1. Copy the edit rule and identify which action it covers.
2. Read the activity sender, action, note and owner. Compare the activity action with the action named in the rule.
3. Rubric: A is reading note 7 owned by A. The printed edit rule alone does not decide whether that read is permitted; a read policy is missing.
4. Stop at that stated uncertainty. No WebSocket connection is required.

04Client-side case

Allow about fifteen minutes for the self-review case. For each row, state whether the decision belongs at a DOM insertion, a browser origin/framing boundary or a server action check. Explain one limit of the evidence. Core topics help prepare for later stages, while the map and advanced topics remain part of full Web security completion.

Original fictional client-side self-review. About fifteen minutes.

1. A paragraph must display the characters <b>tea</b>. Identify which kind of insertion keeps them as text and why.
2. POST /notes/12 carries the login cookie and token copper; the session expects silver. Apply the matching rule.
3. A browser preflight names an origin different from the response allow-origin. State the mismatch and what this does not establish about authorization.
4. An untrusted site tries to embed the notes page. Compare the parent policy with the color policy.
5. A connected socket from A sends an edit for note 7, owned by A. Apply the edit rule.

Rubric: text insertion preserves characters; the mismatched token fails; the preflight fails this origin check but does not supply an action-permission result; the parent policy restricts embedding; the same-owner edit satisfies the rule.
For each answer, cite the relevant fact and state that this is a model, not a live browser exchange.

05Optional challenge

Say what should happen to later messages if the session on the card has expired. The rubric is: the connection's earlier acceptance does not keep those messages authorized. About ten minutes.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

S1: the server accepts a connection upgrade for authenticated Lina.
S2: Lina sends an edit message for note 33, owner Lina.
S3: Lina sends an edit message for note 34, owner Oren.
S4: Lina sends a read message for note 35, owner Lina.
Policy supplied here: Lina may edit only notes owned by Lina. No read policy is supplied.
No socket connection or message was sent.

07Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: separate connection acceptance from message authorization; cite action and stored owner; avoid inventing a read policy from an edit rule; identify later validation and session-expiry checks.