Skip to main content

Appendix E. Guidance for Clients Desiring to Authenticate (希望进行身份验证的客户端指南)

附录 E. Guidance for Clients Desiring to Authenticate (希望进行身份验证的客户端指南)​

许多已经实现的 WebDAV 客户端都有账户设置 (类似于电子邮件客户端存储 IMAP 账户设置的方式)。因此, 如果 WebDAV 客户端有办法从服务器获取带有域名、nonce 和其他质询信息的身份验证质询, 它就能够在向服务器发出的前几个请求中进行身份验证。请注意, 某些请求的结果可能会根据客户端是否经过身份验证而有所不同 -- 如果客户端经过身份验证, PROPFIND 可能会返回更多可见资源, 但如果客户端是匿名的, 则不会失败。

客户端可以通过多种方式触发服务器提供身份验证质询。本附录描述了几种似乎特别有可能工作的方法。

第一种方法是执行应该需要身份验证的请求。但是, 服务器可能即使没有身份验证也能处理任何请求, 因此为了完全安全, 客户端可以添加条件头以确保即使请求通过权限检查, 服务器也不会实际处理它。遵循这种方法的一个例子是使用带有 "If-Match" 头和编造的 ETag 值的 PUT 请求。如果服务器不按要求在测试条件之前测试授权 (参见第 8.5 节), 或者服务器不需要测试授权, 则此方法可能无法导致身份验证质询。

示例 - 使用写请求强制身份验证质询

>>Request

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

第二种方法是使用 Authorization 头 (在 [RFC2617] 中定义), 服务器可能会拒绝该头, 但随后会提示适当的身份验证质询。例如, 客户端可以从包含 Authorization 头的 PROPFIND 请求开始, 该头包含编造的 Basic userid:password 字符串或实际可信的凭据。这种方法依赖于服务器在收到带有无法识别的用户名、无效密码的 Authorization 头时, 或者如果它甚至不处理基本身份验证时, 用 "401 Unauthorized" 和质询进行响应。由于 RFC 2617 的要求, 这似乎很可能有效:

"如果源服务器不希望接受随请求发送的凭据, 它应该返回 401 (Unauthorized) 响应。响应必须包含一个 WWW-Authenticate 头字段, 其中包含至少一个适用于所请求资源的 (可能是新的) 质询。"

在某些情况下实现该建议时存在一个小问题, 因为某些服务器甚至没有某些资源的质询信息。因此, 当无法对资源进行身份验证或资源在所有接受的方法上完全公开可用时, 服务器可以忽略 Authorization 头, 客户端可能会稍后重试。

示例 - 使用 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]
Last updated on