Hallo Ralf,
nichtsdestotrotz sind HTTP Authentication und Authentication mit Cookies zwei sehr verschiedene Dinge mit verschiedenen Problemen.
HTTP Authentication ist ein eigenes, anwendungsunabhängiges Framework mit eigenen Headern, und eine gelungene Authentication gilt zunächst einmal für den kompletten Origin bzw. einen Realm darin.
Cookies, die eine gelungene Authentication speichern, sind dagegen abhängig vom Ressourcen-Path und werden nicht vom Server, sondern von einer Application gesetzt. Es ist eine Entscheidung der Application, für welchen Path sie den Cookie setzt.
Credentials an die Subdomain (...) unaufgefordert mitsenden
Henry verwendet keine Subdomain. Er hat eine dyndns-Adresse und darunter Pfade. Zumindest deute ich eine Beschreibung so. HTTP Authentication und Subdomains vertragen sich eh nicht. Nachdem der Browser einmal von example.org einen WWW-Authenticate Header bekommen und erfolgreich beantwortet hat, schickt er den Authorization-Header dazu bei allen Requests an example.org mit. Er tut es nicht bei www.example.org. Ob er sich auch merkt, dass bestimmte Pfade Authenticate-Requests mit verschiedenen Realms liefern und er die Credentials dazu sauber zuordnet - keine Ahnung. Dazu müsste ich rumexperimentieren.
Bei Cookies kann ich explizit Sichtbarkeiten für Domains und Pathes festlegen. Das hängt davon ab, wie der Cookie gesetzt wird. Ein Cookie, der mit Set-Cookie ... domain=selfhtml.org,path=/self gesetzt wird, wird gesendet beim Abruf von
forum.selfhtml.org/self
forum.selfhtml.org/self/2021
wiki.selfhtml.org/self
und nicht gesendet für
forum.selfhtml.org/meta
wiki.selfhtml.org/wiki
forum.se1fhtml.org/self
(na? gesehen?)
Rolf
sumpsi - posui - obstruxi