Erst die Sitzung, dann der Schluessel

Der Schluessel kennt keinen Nutzer und landete beim Standardnutzer — auch
dann, wenn die App unter derselben Site liegt und der Browser das
HoneyOS-Cookie laengst mitschickt (cloud.honeyos.… und honeyos.… sind
dieselbe Site, duckdns.org steht auf der Public-Suffix-Liste). Damit trug
die HoneyBar in Aether die Farben eines fremden Nutzers.

Jetzt sieht /api/apps erst nach der Sitzung, und nur bei eigener
Anmeldung: Im offenen Betrieb und hinter einem Anmelde-Proxy gilt jede
Anfrage als angemeldet, dort bleibt der Schluessel das letzte Wort.
Test dazu, mit zwei Nutzern, damit der Rueckfall auf den einzigen Nutzer
das Ergebnis nicht zufaellig richtig aussehen laesst.

README.md

@@ -90,12 +90,25 @@ Zweite Schranke, unabhängig davon: HoneyOS gibt die Liste nur an Ursprünge
 heraus, die **selbst als App eingetragen** sind. Eine fremde Seite scheitert
 also an CORS, selbst mit richtigem Schlüssel.
 
-**Was auf zwei Sites nicht geht:** der Anmeldestand auf den Kacheln des
-Schreibtischs (fragt über die Domaingrenze). Der Name *in der HoneyBar* geht
-weiterhin — den holt sie bei der App selbst, gleicher Ursprung.
+**Erst die Sitzung, dann der Schlüssel.** Bringt die Anfrage ein gültiges
+HoneyOS-Cookie mit, antwortet der Server mit den Einstellungen **dieses**
+Nutzers; der Schlüssel wird dann gar nicht erst angesehen. Er ist die Krücke
+für den Fall, dass das Cookie nicht ankommen kann — und darf eine echte
+Anmeldung nicht überstimmen, denn er kennt keinen Nutzer und landet beim
+Standardnutzer.
 
-Liegen alle Adressen unter derselben Domain (`os.honeyy…`, `cloud.honeyy…`),
-entfällt der Schlüssel und alles funktioniert ohne Einschränkung.
+Ob das Cookie ankommt, entscheidet die **Site**, nicht die Adresse: Weil
+`duckdns.org` auf der Public-Suffix-Liste steht, sind `honeyos.duckdns.org` und
+`cloud.honeyos.duckdns.org` **dieselbe** Site (Cookie fließt),
+`honeyy.duckdns.org` dagegen eine fremde (Cookie fließt nicht).
+
+| | Cookie | Folge |
+|---|---|---|
+| App unter derselben Site | kommt an | eigene Röhre, eigenes Wetter, `data-key` überflüssig |
+| App auf fremder Site | bleibt weg | Schlüssel nötig, HoneyBar trägt die Farben des Standardnutzers |
+
+Zweiteres gilt auch für den Anmeldestand auf den Kacheln des Schreibtischs: Der
+fragt über die Domaingrenze und bleibt dort leer.
 
 ## Apps anlegen