Welche Cookies mitgehen

Wenn Ana sich anmeldet, setzt die Antwort das Session-Cookie, und ein Browser legt es in seinen Cookie-Speicher. Im Modell ist der Speicher eine Liste und ein Cookie ein Dict. Hier ist die Header-Zeile aus Kapitel 4 und das Dict, das daraus wird, mit gekürztem Wert. Der Header ist eine Zeile, hier nach Max-Age umbrochen, damit er auf die Seite passt:

set-cookie: __Host-session=<22 characters>; HttpOnly; Max-Age=28800;
            Path=/; SameSite=Lax; Secure

{
    "name": "__Host-session",
    "value": "<22 characters>",
    "host": "reading.example",
    "path": "/",
    "secure": True,
    "samesite": "Lax",
}

host ist der Host, der das Cookie gesetzt hat. samesite ist "Strict", "Lax", "None" oder "" für ein Cookie, das keins nennt.

Bei jeder Anfrage, die eine Seite startet, fragt der Browser jedes Cookie im Speicher: Geht dieses mit? Es gibt vier Prüfungen, in dieser Reihenfolge: Host, Pfad, Secure, SameSite. Ein Cookie, das eine nicht besteht, bleibt zu Hause. cookies_to_send(jar, url, page_origin, *, method, top_level) ist diese Schleife. url ist das Ziel der Anfrage, und page_origin ist die Origin der Seite, die sie gestartet hat.

Host

Das Cookie geht nur an genau den Host, der es gesetzt hat: cookie["host"] muss gleich urlsplit(url).hostname sein. Das Session-Cookie nennt keine Domain, also bekommt app.reading.example es nie.

Die Prüfung vergleicht Hosts, nicht Origins. Ein Cookie ist an keinen Port gebunden, also trägt eine Anfrage an https://reading.example:8443 die Cookies von https://reading.example.

Pfad

Ein Cookie geht an seinen eigenen Pfad und an jeden Pfad darunter. path_matches(cookie_path, request_path) ist in drei Fällen wahr:

1. die beiden Pfade sind gleich;

2. der Anfragepfad beginnt mit dem Cookie-Pfad, und der Cookie-Pfad endet auf /;

3. der Anfragepfad beginnt mit dem Cookie-Pfad, und sein nächstes Zeichen ist /.

Also passt Path=/books zu /books/7. Es passt nicht zu /booksx, das mit denselben Buchstaben beginnt und ein anderer Pfad ist. Path=/ passt zu allem. Eine URL ohne Pfad, etwa https://reading.example, fragt nach /.

Secure

Ein Secure-Cookie geht nur an eine https-URL. HTTP with Python hat Secure weggelassen, weil sein Server einfaches HTTP sprach. Kapitel 4 hat es eingeschaltet. Diese Prüfung ist die Regel, die dem Flag Bedeutung gibt.

SameSite

Zuerst fragt der Browser, ob die Anfrage innerhalb einer Site bleibt: same_site(page_origin, url), mit deiner Funktion aus Lektion 2. Wenn ja, darf jedes Cookie mitgehen. Wenn nein, entscheidet das Attribut:

• Strict: Das Cookie bleibt zu Hause.

• Lax: Das Cookie geht nur bei einer Top-Level-Navigation mit, deren Methode GET oder HEAD ist. Im Modell sind ein angeklickter Link und ein abgeschicktes Formular Top-Level-Navigationen: Die Antwort wird zu der Seite, die der Leser sieht. Ein Bild und eine Anfrage, die ein Skript stellt, sind es nicht. Ein Link ist ein GET, ein Formular kann GET oder POST senden, und keine Seitennavigation verwendet HEAD. Über Sites hinweg lässt Lax das Cookie also bei einem angeklickten Link oder einem mit GET gesendeten Formular mitgehen und nie bei einem Formular-POST, einem Bild oder der Anfrage eines Skripts. Deshalb besteht Lektion 8 darauf, dass kein GET etwas ändert.

• None: Das Cookie geht immer mit.

• Kein Attribut: Dieses Modell behandelt das Cookie als Lax, wie Chromium.

samesite_allows(samesite, *, same_site_request, method, top_level) antwortet für ein Cookie. Das * macht die drei Namen danach zu reinen Schlüsselwortargumenten. Das mitgelieferte Set LAX_METHODS enthält "GET" und "HEAD". Vier Antworten in dieser Tabelle bleiben dir überlassen:

Was ein Browser nicht speichert

Manche Cookies erreichen den Speicher nie. may_store(cookie, url) gibt für drei davon False zurück:

• ein Secure-Cookie, das eine Antwort von einer http-URL setzt;

• ein Cookie mit SameSite=None und ohne Secure;

• ein Cookie, dessen Name mit __Host- beginnt und das nicht Secure ist oder dessen Pfad nicht / ist.

Kapitel 4 hat das Präfix __Host- als Versprechen gewählt. Hier ist der Code, der einen Server daran festhält.

Deine Aufgabe

Schreibe in mini_browser.py die vier Funktionen, die für Lektion 3 markiert sind, in dieser Reihenfolge: path_matches, samesite_allows, may_store, cookies_to_send. Die letzte geht den Speicher durch, wendet die vier Prüfungen mit continue an und gibt eine neue Liste der Cookies zurück, die mitgehen, in der Reihenfolge des Speichers. Sie ändert den Speicher nie.

Fülle jedes Fragezeichen, indem du deine Funktion fragst. Diese Zeile fragt nach dem ersten:

python -c "import mini_browser; print(mini_browser.samesite_allows('Lax', same_site_request=False, method='GET', top_level=False))"

tests/steps.py enthält die vier Seiten-Origins als OWN, APP, NOTES und OTHER. Schreibe dann zwei Tests in tests/test_browser.py. Jeder baut einen Speicher mit einem Cookie-Dict wie dem oben auf dieser Seite und ruft mini_browser.cookies_to_send für einen Formular-POST an steps.OWN + "/books/delete" auf, mit method="POST" und top_level=True:

• test_lax_cookie_stays_home_on_a_cross_site_post: von steps.OTHER aus ist das Ergebnis [].

• test_lax_cookie_travels_within_the_site: von steps.NOTES aus ist das Ergebnis gleich dem Speicher.

Führe dann beide aus:

python -m pytest -q tests/test_browser.py
python mini_browser.py

Der erste endet mit 2 passed. In der Tabelle des zweiten zeigt die letzte Spalte jetzt True, True, True, False: Von den vier Seiten postet nur die auf other.example ihr Formular ohne das Cookie.

Wo sich Modell und echte Browser in dieser Lektion unterscheiden:

• Ein fehlendes SameSite. Das Modell behandelt es als Lax, wie Chromium und wie der aktuelle Entwurf des Cookie-Standards es sagt. Chromium lässt ein solches Cookie außerdem in seinen ersten zwei Minuten bei einem Cross-Site-Top-Level-POST mitgehen, eine Ausnahme, die der Entwurf erlaubt. Firefox und Safari behandeln ein fehlendes SameSite als None.

• SameSite=None ohne Secure. Chromium und Firefox weigern sich, es zu speichern, wie das Modell. Safari speichert es.

• Das Schema in einer Site. Chromium zählt http://reading.example und https://reading.example als zwei Sites, wie das Modell. Firefox und Safari zählen sie als eine, wenn sie SameSite anwenden.

• localhost. Chrome und Firefox akzeptieren ein Secure-Cookie von http://localhost, Safari nicht. Das Modell akzeptiert keins.

• Das Präfix. Der Entwurf erkennt __Host- ohne Rücksicht auf Groß- und Kleinschreibung, das Modell erkennt es nur genau so.

• Weggelassen. Das Attribut Domain, der zeitliche Ablauf, die Partitionierung von Cookies und das Blockieren von Cookies, die an Dritte gesendet werden.

Klicke dann auf Check my work.