HTTP-Authentifizierung

Das Modul httpx stellt einen Mixin zur Durchführung von HTTP-Authentifizierung (sowohl für Proxy- als auch für Origin-Server-Authentifizierung) bereit. Dieser Mixin (httpx.HandleAuthentication) kann mit den Klassen HTTPConnection und HTTPSConnection kombiniert werden (der Mixin könnte möglicherweise auch mit den HTTP- und HTTPS-Kompatibilitätsklassen funktionieren, dies ist jedoch keine Anforderung).

Der Mixin delegiert den Authentifizierungsprozess an ein oder mehrere "Authentifizierungs"-Objekte, wodurch mehrere Verbindungen Authentifizierungs-Objekte gemeinsam nutzen können. Die Verwendung eines separaten Objekts ermöglicht eine langfristige Verbindung zu einem Authentifizierungssystem (z. B. LDAP). Es wird ein Authentifizierungs-Objekt für die Mechanismen Basic und Digest (siehe RFC 2617) bereitgestellt. Vom Benutzer bereitgestellte Unterklassen von Authentifizierungs-Objekten können registriert und von den Verbindungen verwendet werden.

Ein "Anmeldeinformations"-Objekt (httpx.Credentials) ist ebenfalls mit dem Mixin verknüpft und speichert die für die Authentifizierungs-Objekte benötigten Anmeldeinformationen (z. B. Benutzername und Passwort). Unterklassen von Credentials können erstellt werden, um zusätzliche Informationen zu speichern (z. B. NT-Domäne).

Der Mixin überschreibt die Methode getresponse(), um Antworten mit den Codes 401 (Unauthorized) und 407 (Proxy Authentication Required) zu erkennen. Wenn dies erkannt wird, werden das Antwortobjekt, die Verbindung und die Anmeldeinformationen an das Authentifizierungs-Objekt übergeben, das dem in der Antwort angegebenen Authentifizierungsschema entspricht (mehrere Authentifizierungs-Objekte werden in absteigender Reihenfolge der Sicherheit versucht, wenn mehrere Schemata in der Antwort vorhanden sind). Jedes Authentifizierungs-Objekt kann die Antwort-Header untersuchen und entscheiden, ob und wie die Anfrage mit den richtigen Authentifizierungs-Headern erneut gesendet werden soll. Wenn kein Authentifizierungs-Objekt die Authentifizierung erfolgreich handhaben kann, wird eine Ausnahme ausgelöst.

Das erneute Senden einer Anfrage mit den entsprechenden Anmeldeinformationen ist einer der schwierigeren Teile des Authentifizierungssystems. Die Schwierigkeit liegt darin, zu erfassen, was ursprünglich gesendet wurde: die Request-Zeile, die Header und der Body. Durch Überschreiben von putrequest, putheader und endheaders können wir alles außer dem Body erfassen. Sobald die Methode endheaders aufgerufen wird, erfassen wir alle Aufrufe von send() (bis zum nächsten Aufruf der Methode putrequest), um den Body-Inhalt zu speichern. Der Mixin hat ein konfigurierbares Limit für die Menge der Daten, die auf diese Weise gespeichert werden sollen (z. B. nur bis zu 100 KB Body-Inhalt speichern). Unter der Annahme, dass der gesamte Body gespeichert wurde, können wir die Anfrage mit den entsprechenden Authentifizierungsinformationen erneut senden.

Wenn der Body zu groß zum Speichern ist, gibt getresponse() einfach das Antwortobjekt zurück, das den 401- oder 407-Fehler anzeigt. Da die Authentifizierungsinformationen berechnet und zwischengespeichert wurden (im Credentials-Objekt; siehe unten), kann der Aufrufer die Anfrage einfach neu generieren. Der Mixin wird die entsprechenden Anmeldeinformationen anhängen.

Ein "Schutzraum" (siehe RFC 2617, Abschnitt 1.2) ist definiert als ein Tupel aus Host, Port und Authentifizierungsbereich. Wenn eine Anfrage anfänglich an einen HTTP-Server gesendet wird, kennen wir den Authentifizierungsbereich nicht (der Bereich wird erst zurückgegeben, wenn die Authentifizierung fehlschlägt). Wir haben jedoch den Pfad aus der URL, und dieser kann nützlich sein, um die an den Server zu sendenden Anmeldeinformationen zu ermitteln. Das Basic-Authentifizierungsschema ist typischerweise hierarchisch aufgebaut: die Anmeldeinformationen für /path können für /path/subpath versucht werden. Das Digest-Authentifizierungsschema unterstützt explizit den hierarchischen Aufbau. Das httpx.Credentials-Objekt speichert Anmeldeinformationen für mehrere Schutzräume und kann auf zwei verschiedene Arten abgerufen werden

1. abgerufen unter Verwendung von (host, port, path) – dieses Abrufschema wird beim Generieren einer Anfrage für einen Pfad verwendet, bei dem wir den Authentifizierungsbereich nicht kennen.
2. abgerufen unter Verwendung von (host, port, realm) – dieser Mechanismus wird während des Authentifizierungsprozesses verwendet, wenn der Server angegeben hat, dass die Request-URI innerhalb eines bestimmten Bereichs liegt.

Der HandleAuthentication-Mixin überschreibt putrequest(), um Anmeldeinformationen automatisch einzufügen, falls verfügbar. Die URL aus putrequest wird verwendet, um die entsprechenden Authentifizierungsinformationen zu ermitteln.

Es ist auch wichtig zu beachten, dass zwei Sätze von Anmeldeinformationen verwendet und vom Mixin gespeichert werden. Einer für jeden verwendeten Proxy und einer für den Ziel-Origin-Server. Da Proxys keine Pfade haben, wird für die Schutzräume in den Proxy-Anmeldeinformationen immer "/" zum Speichern und Abrufen über einen Pfad verwendet.

Proxy-Handhabung

Das Modul httpx stellt einen Mixin zur Verwendung eines Proxys für HTTP(S)-Operationen bereit. Dieser Mixin (httpx.UseProxy) kann mit den Klassen HTTPConnection und HTTPSConnection kombiniert werden (der Mixin könnte möglicherweise auch mit den HTTP- und HTTPS-Kompatibilitätsklassen funktionieren, dies ist jedoch keine Anforderung).

Der Mixin speichert die (host, port) des zu verwendenden Proxys. XXX wird überschrieben, um diese Host/Port-Kombination für Verbindungen zu verwenden und die Request-URLs in absoluteURIs umzuschreiben, die auf den Origin-Server verweisen (diese URIs werden an den Proxy-Server übergeben).

Proxy-Authentifizierung wird von der Klasse httpx.HandleAuthentication gehandhabt, da ein Benutzer direkt HTTP(S)Connection verwenden kann, um mit Proxys zu sprechen.

WebDAV-Funktionen

Das Modul davlib stellt einen Mixin zum Senden von WebDAV-Anfragen an einen WebDAV-fähigen Server bereit. Dieser Mixin (davlib.DAVClient) kann mit den Klassen HTTPConnection und HTTPSConnection kombiniert werden (der Mixin könnte möglicherweise auch mit den HTTP- und HTTPS-Kompatibilitätsklassen funktionieren, dies ist jedoch keine Anforderung).

Der Mixin stellt Methoden zur Durchführung der verschiedenen HTTP-Methoden bereit, die in RFC 2616 definierten HTTP-Methoden und in RFC 2518 durch WebDAV definiert sind.

Ein benutzerdefiniertes Antwortobjekt wird verwendet, um Antworten mit dem Code 207 (Multi-Status) zu dekodieren. Das Antwortobjekt verwendet das xml-Paket der Standardbibliothek, um die Multistatus-XML-Informationen zu parsen und eine einfache Struktur von Objekten zu erzeugen, die die Multistatus-Daten speichern. Mehrere Parsing-Schemata werden versucht/verwendet, in absteigender Reihenfolge der Geschwindigkeit.