Cookies Across Origins

The front end can read the book list once it holds a token. So far a test handed it one. A real page has to get its token somewhere.

POST /tokens gives a token to a logged-in session, and the session lives in a cookie of reading.example. So the front end’s page must send a request to another origin with ana’s cookie on it, and read the answer. Both parts need a rule that the model does not have yet.

A fetch leaves cookies at home unless asked

In Chapter 8 every request considered the jar. That was right for those requests: a form, a link, and a plain image always do. A script’s fetch does so only for its own origin. For another origin it leaves every cookie at home, unless the page asks for credentials. In the model that is "credentials": True in the wanted dict.

attaches_cookies(kind, url, page_origin, *, credentials) states that rule: True for every kind but "fetch", True for a fetch to the page’s own origin, and otherwise whatever credentials says. It answers whether cookies are considered at all. Which cookies then go is still the business of cookies_to_send.

A stricter permission

A response to a request that carried a cookie may hold what only the logged-in reader should see. So a browser asks more of the server before a page may read it:

• Access-Control-Allow-Origin must name the page’s exact origin. A * is not accepted.

• The response must also say Access-Control-Allow-Credentials: true, in exactly that spelling.

may_read gets this rule in place of the return False of Lesson 2. The same holds for a preflight that comes before a request with credentials. preflight_allows gets a keyword-only argument, credentials=False. It hands the value on to may_read, and when it is true, a * in the list of methods or in the list of headers counts for nothing.

On the server, cors_headers gets the same keyword. With credentials=True, an origin that is allowed also gets access-control-allow-credentials: true. An origin that is not allowed gets neither header.

Follow the token

Here is the front end’s POST /tokens, one decision at a time.

1. The request has no body and no header of the page’s own. It is a simple request, so no preflight is sent.

2. The page asked for credentials, so attaches_cookies says yes. The session cookie is SameSite=Lax, and the two hosts are one site, so cookies_to_send lets it go.

3. The browser adds Origin: https://app.reading.example. Your server checks that header on this route since Chapter 8, and today it would refuse. The front end’s origin has to join state["trusted_origins"].

4. The server makes a token. cors_headers, with credentials=True, names the front end’s origin and allows credentials.

5. may_read finds the exact origin and true, and the page reads its token.

A page on notes.reading.example can send the same POST. It is on the same site and may ask for credentials too, so ana’s cookie goes along. The Origin check refuses it with 403 before any token is made. And the page could not have read an answer anyway, because no response names its origin.

One set

After step 3 your state would hold the same decision twice: cors_origins for reading, trusted_origins for the Origin check. Two sets that must agree will one day disagree. Delete cors_origins from sample_state(), put the front end’s origin into trusted_origins, and pass that one set to every call of cors_headers.

The service’s own origin is now in the set that CORS uses. That changes nothing, because a page never needs CORS to read its own origin.

The front end has gained something too. Every POST that the Origin check guards now accepts it, so its page can send POST /logout and log ana out. An origin you let read with credentials is an origin you trust with the session.

Trust has a limit. The front end still cannot post the delete form: POST /books/delete asks for the token from the reading list’s own page, and the front end’s page does not have it.

Only two routes answer with credentials: GET /me and POST /tokens. The book routes need none. A bearer token that a script puts in a header is not a credential in the browser’s sense, and no cookie is read there.

Read the rest of visit.py

Open visit.py and find the block marked Chapter 9. Its nine lines call four functions, and you wrote all of them. From now on visit() carries a fetch to another origin from start to finish.

Your task

In mini_browser.py: write attaches_cookies, and grow may_read and preflight_allows.

In reading_server.py: add the keyword to cors_headers, make the change to sample_state(), and pass state["trusted_origins"] in the three calls you have. Then add one line to the "/me" branch, in the case for GET and HEAD, and the same line to the "/tokens" branch, in the case for POST:

            response = add_headers(response, cors_headers(request, state["trusted_origins"], credentials=True))

Then watch the whole exchange on loopback:

python -m pytest -q
python pl_sec.py cors

The tests end in 37 passed. The scenario plays the front end, then the neighbor, then another site. This is the front end’s first request and the neighbor’s last:

--- the front end, https://app.reading.example: POST /tokens, and it asks for credentials ---
  sent: POST /tokens   cookie: yes   token: no   origin: https://app.reading.example
  your server answered 200
        access-control-allow-origin: https://app.reading.example
        access-control-allow-credentials: true
        vary: Origin
  the page may read the response: yes
  the page now holds a token (not shown)

  sent: GET /me   cookie: yes   token: no   origin: https://notes.reading.example
  your server answered 200
        vary: Origin
  the page may read the response: no (the response did not give this origin permission to read it)

The last line of the result says the front end read 4 of 4 responses; pages on other origins read 0 of 4; the request without an Origin header was answered 200.

The model has cookies only. In the standard, credentials also covers a login that the browser remembers for HTTP authentication, and client certificates. And the front end is lucky to share a site with the service. A front end on another site would need the session cookie to be SameSite=None, which is a larger decision than this lesson makes. Even then a browser may withhold the cookie. Safari blocks cookies that go to a third party, Firefox keeps a separate cookie jar for each site, and Chrome sends them unless the user has turned that off or is in an Incognito window.

Then press Check my work.