Appendix E. Guidance for Clients Desiring to Authenticate (Anleitung für Clients, die sich authentifizieren möchten)

Anhang E. Guidance for Clients Desiring to Authenticate (Anleitung für Clients, die sich authentifizieren möchten)

Viele WebDAV-Clients, die bereits implementiert wurden, haben Kontoeinstellungen (ähnlich wie E-Mail-Clients IMAP-Kontoeinstellungen speichern). Daher wäre der WebDAV-Client in der Lage, sich mit seinen ersten paar Anfragen an den Server zu authentifizieren, vorausgesetzt, er hätte eine Möglichkeit, die Authentifizierungs-Challenge vom Server mit Realm-Name, Nonce und anderen Challenge-Informationen zu erhalten. Beachten Sie, dass die Ergebnisse einiger Anfragen variieren können, je nachdem, ob der Client authentifiziert ist oder nicht -- ein PROPFIND könnte mehr sichtbare Ressourcen zurückgeben, wenn der Client authentifiziert ist, aber nicht fehlschlagen, wenn der Client anonym ist.

Es gibt eine Reihe von Möglichkeiten, wie der Client den Server dazu bringen kann, eine Authentifizierungs-Challenge bereitzustellen. Dieser Anhang beschreibt einige Ansätze, die besonders wahrscheinlich funktionieren.

Der erste Ansatz besteht darin, eine Anfrage auszuführen, die eine Authentifizierung erfordern sollte. Es ist jedoch möglich, dass ein Server jede Anfrage auch ohne Authentifizierung behandelt, daher könnte der Client, um völlig sicher zu sein, einen bedingten Header hinzufügen, um sicherzustellen, dass die Anfrage selbst dann nicht tatsächlich vom Server behandelt wird, wenn sie Berechtigungsprüfungen besteht. Ein Beispiel für die Verfolgung dieses Ansatzes wäre die Verwendung einer PUT-Anfrage mit einem "If-Match"-Header mit einem erfundenen ETag-Wert. Dieser Ansatz könnte nicht zu einer Authentifizierungs-Challenge führen, wenn der Server nicht wie erforderlich die Autorisierung vor den Bedingungen testet (siehe Abschnitt 8.5) oder wenn der Server die Autorisierung nicht testen muss.

Beispiel - Erzwingen einer Auth-Challenge mit Schreibanfrage

>>Request

  PUT /forceauth.txt HTTP/1.1
  Host: www.example.com
  If-Match: "xxx"
  Content-Type: text/plain
  Content-Length: 0

Der zweite Ansatz besteht darin, einen Authorization-Header (definiert in [RFC2617]) zu verwenden, der wahrscheinlich vom Server abgelehnt wird, aber dann eine ordnungsgemäße Authentifizierungs-Challenge auslöst. Der Client könnte beispielsweise mit einer PROPFIND-Anfrage beginnen, die einen Authorization-Header mit einer erfundenen Basic-userid:password-Zeichenfolge oder mit tatsächlichen plausiblen Anmeldeinformationen enthält. Dieser Ansatz verlässt sich darauf, dass der Server mit einem "401 Unauthorized" zusammen mit einer Challenge antwortet, wenn er einen Authorization-Header mit einem nicht erkannten Benutzernamen, einem ungültigen Passwort erhält oder wenn er nicht einmal die Basis-Authentifizierung verarbeitet. Dies scheint aufgrund der Anforderungen von RFC 2617 wahrscheinlich zu funktionieren:

"Wenn der Ursprungsserver die mit einer Anfrage gesendeten Anmeldeinformationen nicht akzeptieren möchte, SOLLTE er eine 401 (Unauthorized)-Antwort zurückgeben. Die Antwort MUSS ein WWW-Authenticate-Header-Feld enthalten, das mindestens eine (möglicherweise neue) Challenge enthält, die auf die angeforderte Ressource anwendbar ist."

Es gibt ein kleines Problem bei der Implementierung dieser Empfehlung in einigen Fällen, da einige Server nicht einmal Challenge-Informationen für bestimmte Ressourcen haben. Wenn es also keine Möglichkeit gibt, sich bei einer Ressource zu authentifizieren, oder die Ressource über alle akzeptierten Methoden vollständig öffentlich verfügbar ist, KANN der Server den Authorization-Header ignorieren, und der Client wird vermutlich später erneut versuchen.

Beispiel - Erzwingen einer Auth-Challenge mit Authorization-Header

>>Request

  PROPFIND /docs/ HTTP/1.1
  Host: www.example.com
  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  Content-type: application/xml; charset="utf-8"
  Content-Length: xxxx

  [body omitted]