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 要求が行われ、これにより、Identity Server コールバック URL の場所 ( https://identityserver.example.com/connect/authorize/callback?client_idなど) を含む 302 が返されます。 =WebDAV&response_type=code%20id_token%20token ...
- この URL に対して GET 要求が行われ、アイデンティティ サーバー情報 (トークン) が設定されたクライアント コールバック URL (例: https://webdav.example.com/account/callback ) に POST されます。
- これは、Identity Server のアクセス トークンを Cookie に保存し (Office が Cookie を使用できるようにするため)、https://webdav.example.com/account/successの場所を含む 302 で応答するカスタム エンドポイントです。この URL は、X-FORMS_BASED_AUTH_RETURN_URL ヘッダーで構成されたものと同じです。
Windows クライアントでは、これはすべて正常に動作します。ただし、Mac (Mac OS Sierra 10.12.6) で Office 2016 (16.11.1 (180319)) を使用している場合、https ://webdav.example.com/account/callback URL から 302 応答が返されますが、https://webdav.example.com/account/successに対して行われる GET リクエストはありません。さらに、さらに WebDAV リクエストが行われ、コードをステップ実行すると、Cookie を実行するためのコードがエラーなしで実行されているにもかかわらず、Mac で Cookie が設定されていないように見えることがわかります。
どうしたの？
ありがとう、スチュアート。