ユーザーがユーザー名、パスワード、ドメインでログインするアプリケーションを作成しています。Windows プラットフォーム間で再利用できるようにしたいので、ポータブル クラス ライブラリで Microsoft HTTP クライアント ライブラリの nuget パッケージを使用しています。
ここでは、HttpClientHandler を使用して HttpClient を作成し、GetAsync を呼び出す方法を示します。
HttpClientHandler handler = new HttpClientHandler();
ICredentials myCredentials = new NetworkCredential("Username", "Password", "Domain");
handler.Credentials = myCredentials;
HttpClient client = new HttpClient(handler);
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
client.BaseAddress = new Uri("https://....");
HttpResponseMessage response = await client.GetAsync("...");
これはうまくいくようです。資格情報は要求で送信され、登録されたユーザーのみがデータを取得できます。
私のアプリケーションでは、ユーザーはサインアウトしてから、おそらく別のユーザー名、パスワード、またはドメインで再度サインインするオプションもあります。で、ここが問題です。有効な資格情報を使用して client.GetAsync を 1 回呼び出した場合、毎回 HttpClient の新しいインスタンスを作成し、新しいユーザーに正しい資格情報を設定していますが、HttpClient は古いユーザーの資格情報を記憶しているようです。
私の質問は、HttpClient がネットワーク チャネルを開いたままにしているのか、それとも私が認識していないセッションの問題があるのかということです。
--- アップデート #1 ---
GetAsync(...) で URL を一意にすると、たとえば、リクエストでランダムなパラメーターを渡すことができ、サーバーは資格情報を検証し、承認されたユーザーのみがリソースにアクセスできるようになります。それは本当に良い解決策ではないので、さらに調査を行いました。
サーバーが Persistent-Auth: true という応答ヘッダーを送信しているようです。これにより、次のリクエストで Authorization ヘッダーが必要ないことがクライアントに通知されます。次に同じリソースに対して GetAsync を呼び出そうとすると、資格情報が送信されないのはそのためだと思います。驚いたことに、Fiddler では、このリソースへの 2 番目のリクエストで、クライアントから HTTP リクエストがまったく送信されていないことにも気付きました。
興味深い点の 1 つは、ブラウザーで同じアプローチを試すと、Authorization は同じ動作をするため、最初の要求にのみ含まれることです。同じリソースへの 2 番目の要求について、期待どおりに HTTP 要求が送信されていることを Fiddler で確認できます。
それで、すべてを合計します。私は2つの問題で立ち往生していると思います。まず、この Persistent-Auth の動作を変更して、サーバーの応答で false に設定することは可能ですか? 2 番目に、同じリソースを 2 回目に要求したときに、アプリケーションがまったく要求を送信しないのはなぜですか。