Skip to main content

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

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

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

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

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

示例 - 使用写请求强制身份验证质询 (Example - forcing auth challenge with write request)

>>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字符串或实际可信的凭据。此方法依赖于服务器响应"401 Unauthorized"以及质询,如果它收到具有无法识别的用户名、无效密码的Authorization头,或者如果它甚至不处理Basic身份验证。这似乎可能起作用,因为RFC 2617的要求:

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

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

示例 - 使用Authorization头强制身份验证质询 (Example - forcing auth challenge with 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]
Last updated on