メインコンテンツまでスキップ

Appendix E. Guidance for Clients Desiring to Authenticate (認証を希望するクライアントのガイダンス)

附録 E. Guidance for Clients Desiring to Authenticate (認証を希望するクライアントのガイダンス)​

すでに実装されている多くの WebDAV クライアントには、アカウント設定があります (電子メールクライアントが IMAP アカウント設定を保存する方法と同様)。したがって、WebDAV クライアントは、レルム名、nonce、その他のチャレンジ情報を含むサーバーからの認証チャレンジを取得する方法があれば、サーバーへの最初の数回のリクエストで認証できるようになります。一部のリクエストの結果は、クライアントが認証されているかどうかによって異なる可能性があることに注意してください。PROPFIND は、クライアントが認証されている場合、より多くの表示可能なリソースを返す可能性がありますが、クライアントが匿名の場合は失敗しません。

クライアントがサーバーに認証チャレンジを提供させることができる方法はいくつかあります。この附録では、特にうまくいきそうな2つのアプローチについて説明します。

最初のアプローチは、認証が必要なリクエストを実行することです。ただし、サーバーは認証なしでも任意のリクエストを処理する可能性があるため、完全に安全にするために、クライアントは条件ヘッダーを追加して、リクエストが権限チェックを通過した場合でも、サーバーによって実際に処理されないようにすることができます。このアプローチに従う例は、作成した ETag 値で "If-Match" ヘッダーを使用した PUT リクエストを使用することです。このアプローチは、サーバーが要求どおりに条件をテストする前に認証をテストしない場合 (セクション 8.5 を参照)、またはサーバーが認証をテストする必要がない場合、認証チャレンジにつながらない可能性があります。

例 - 書き込みリクエストで認証チャレンジを強制する

>>Request

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

2番目のアプローチは、Authorization ヘッダー ([RFC2617] で定義) を使用することです。これはサーバーによって拒否される可能性がありますが、適切な認証チャレンジを促します。たとえば、クライアントは、作成した Basic userid:password 文字列または実際のもっともらしい資格情報を含む Authorization ヘッダーを含む PROPFIND リクエストから始めることができます。このアプローチは、認識されないユーザー名、無効なパスワードを含む Authorization ヘッダーを受信した場合、または基本認証を処理しない場合に、サーバーが "401 Unauthorized" とともにチャレンジで応答することに依存しています。これは RFC 2617 の要件のために機能する可能性が高いようです:

"オリジンサーバーがリクエストとともに送信された資格情報を受け入れたくない場合、401 (Unauthorized) 応答を返すべきです (SHOULD)。応答には、要求されたリソースに適用可能な少なくとも 1 つの (おそらく新しい) チャレンジを含む WWW-Authenticate ヘッダーフィールドを含める必要があります (MUST)。"

場合によっては、その推奨事項の実装に若干の問題があります。一部のサーバーには、特定のリソースのチャレンジ情報すらないためです。したがって、リソースに認証する方法がない場合、またはリソースが受け入れられたすべてのメソッドで完全に公開されている場合、サーバーは Authorization ヘッダーを無視してもよく (MAY)、クライアントは後で再試行すると推定されます。

例 - Authorization ヘッダーで認証チャレンジを強制する

>>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]
に最終更新