我们有一个使用 IT Hit WebDAV 服务器组件的自定义 WebDAV 解决方案。对于身份验证，我们使用 Identity Server 4 实现。从用户的角度来看，认证流程大致如下：
- 用户在应用程序中单击指向 WebDAV 文档的链接。
- Office（在我们的大多数测试用例中，Word）已打开。
- 如果这是用户第一次打开文档（或 cookie 已过期），则会显示登录对话框。
- 用户输入他们的用户名和密码，点击登录按钮，如果成功，文档就会打开。
在幕后，流程类似于以下内容：
- 向文档的父文件夹发出 HEAD 请求，例如https://webdav.example.com/documents/
- 对此请求的响应包含 Office 显示登录对话框所需的标头。X-FORMS_BASED_AUTH_REQUIRED 等
- Office 遵循来自 X-FORMS_BASED_AUTH_REQUIRED 标头值的 URL。例如https://identityserver.example.com/connect/authorize?client_id=WebDAV&response_type=code+id_token+token ...
- 这将返回一个 302 响应，其位置类似于：https://identityserver.example.com/account/login?returnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3DWebDAV%26response_type%3Dcode%2520id_token%2520token ...
- Office 在对话框中打开此 URL。一旦用户输入他们的凭据并点击登录，就会向登录表单发出 POST 请求，这将返回一个 302，其中包含身份服务器回调 URL 的位置，例如https://identityserver.example.com/connect/authorize/callback?client_id =WebDAV&response_type=code%20id_token%20token ...
- 向此 URL 发出 GET 请求，然后将身份服务器信息（令牌）发布到配置的客户端回调 URL，例如https://webdav.example.com/account/callback。
- 这是一个自定义端点，它将 Identity Server 访问令牌存储在 cookie 中（以便 Office 可以使用 cookie），然后使用位置为https://webdav.example.com/account/success的 302 进行响应。此 URL 与 X-FORMS_BASED_AUTH_RETURN_URL 标头中配置的 URL 相同。
在 Windows 客户端上，这一切都很好。但是在 Mac (Mac OS Sierra 10.12.6) 和使用 Office 2016 (16.11.1 (180319)) 上，我们看到 302 响应是从https://webdav.example.com/account/callback URL 返回的，但它是从未遵循，没有向https://webdav.example.com/account/success发出 GET 请求。此外，还有进一步的 WebDAV 请求并逐步执行代码，我们可以看到 cookie 似乎从未在 Mac 上设置，尽管执行此操作的代码没有错误地执行。
发生什么了？
谢谢，斯图尔特。