IISのアプリケーションプール リサイクル時のセッションについて

もう一つ質問。

ASP.NET Core の Session 情報のストアには分散キャッシュを利用するのですが、それには以下があります。どれを使ってますか？

(1) 分散メモリ キャッシュ - AddDistributedMemoryCache

(2) 分散 SQL Server キャッシュ - AddDistributedSqlServerCache

(3) 分散 Redis キャッシュ - AddStackExchangeRedisCache

(4) 分散 NCache キャッシュ - AddNCacheDistributedCache

コメント頂きありがとうございます。

「インプロセスホスティング」の認識です。

（ASP.NET CoreアプリをIISにデプロイしている）

■コードについて

・クライアント側（javascript(ajax)のpost通信）

// アプリ(.net Core MVC)のView.cshtmlに記載

$.ajax({

url: '/XXXX/TestUpdate',  // Controllerに、画面の値を渡して処理したい

type: 'POST',

data: $('form').serialize(),

timeout: 10000,

dataType: 'text',

cache: false,

}).done(function (data) {

    // 更新した値を画面に表示したい。

    $("#testPartialView").html(data);

}).fail(function (XMLHttpRequest, textStatus, errorThrown) {

});

・サーバー側のコード

// アプリ(.net Core MVC)のController.csに記載

// 引数: testModel は JSからの$('form').serialize()を受け取るためのクラス

[HttpPost]

[ValidateAntiForgeryToken]

public IActionResult TestUpdate(testModel model)

{

 // DB登録など

 return PartialView("_testPartialView", model);

}

ASP.NET Core の Session 情報のストアについては
(1)～(4)のいずれも使っていない認識です。

そもそも分散キャッシュについての知識がなく、意識していませんでした。

なお、現在はProgram.csに以下を記載しているのみです。
builder.Services.AddSession(options => {

options.IdleTimeout = TimeSpan.FromSeconds(30);

});

コードを拝見しましたが、その中では ASP.NET で言う Session は使ってません。質問者さんの言う「セッション」は ASP.NET で言う Session とは違うもののように思えます。

質問者さんの言う「セッション」とは、ユーザーがブラウザで web サイトにアクセスを開始してから終了するまでの一連のやり取りのことのような気がしますが、違いますか？

何にせよ、IIS のワーカープロセスのアカウントをどのようにしたとしても、

管理者権限を持つユーザーはセッション情報が永続的に保持されるためリサイクル後も同じセッションになり

ということはあり得ません。

ASP.NET で言う Session 情報をメモリに保持しているとすれば、リサイクルで間違いなく消えます。また、タイムアウトで Session に格納したデータは削除されます。

SQL Server に保持していれば、リサイクルで消えることはありませんが、タイムアウトで Session に格納したデータは削除されます。

なので、上にも書きましたが、400 Bad Request は Session とは関係ないと思います。

と言って、400 Bad Request の原因は今提供されている情報では自分には分かりませんが。

セッションではなくて別の観点から原因を探す方が良さそうです。

今提供されている情報だけからの想像ですが、怪しいのは CSRF トークンの検証失敗です。そのあたりを確認してはいかがですか？

CSRF 用の隠しフィールドのデータを含めてフォームデータを jQuery ajax を使って POST 送信し、アクションメソッドに付与した [ValidateAntiForgeryToken] 属性での検証ができるようにしているのですよね。

その場合、何らかの原因でクッキーと隠しフィールドにある CSRF 対策用トークンがブラウザから送信されないと 400 Bad Request になります。

例えば、以下のようにクッキーと隠しフィールドにある CSRF 対策用トークンが送信されれば成功しますが、

その後で、ブラウザのクッキーを削除して試すと 400 Bad Request になります。

ちなみに上の画像の検証に使ったのは以下に記事のアプリで、jQuery の .serialize() メソッドを使って form データを POST 送信するというところは質問者さんのケースと同じです。

jQuery ajax で部分ビューの呼出・表示 (CORE) http://surferonwww.info/BlogEngine/post/2020/03/07/use-jquery-ajax-to-request-and-render-partial-view.aspx