6

コード：

Session["foo"] = "bar";  
Response.Redirect("foo.aspx");

問題：

foo.aspx がセッションから "foo" を読み取るとき、そこにはありません。セッションは存在しますが、「foo」の値はありません。

これは、実稼働環境で断続的に観察されました。しかし、ここでResponse.Redirect() について質問するつもりはありません。

説明：

Bertrand Le Royは次のように説明しています (太字は私のものです)。

ここで Redirect が行うことは、クライアントに特別なヘッダーを送信して、サーバーが待っていたページとは別のページをサーバーに要求することです。サーバー側では、このヘッダーを送信した後、Redirect が応答を終了します。 これは非常に暴力的な行為です。 Response.End は、ThreadAbortException を使用しているページの実行を実際に停止します。ここで実際に起こることは、 セッション トークンが戦闘で失われることです。

ここでのポイントは、Response.Redirect() はスレッドの終了に手間がかかる可能性があるということです。そして、セッションの書き込みがあまりにも重い手の近くで発生すると、セッションの書き込みが脅かされる可能性があります。

質問：

ASP.NET セッション管理については、これに対して非常に脆弱です。Response.Redirect() コード行は、セッション書き込み行が「終了」するまで実行を開始しません。セッション書き込みに対する脅威となるのはどうしてですか?

次のコード行が実行される前にセッション書き込みが「終了」しないのはどうですか? セッションの書き込みが同様に (発生しなかったかのように) 失われるシナリオは他にありますか?

4

3 に答える 3

1

いくつかの選択肢（Response.Redirect（...、false）、Server.Transfer（）、および今では思い出せないその他の「解決策」）をテストした結果、この問題に対する信頼できる答えは1つしか見つかりませんでした。

セッション状態をInProcからSqlServerに移動すると、システムからこの動作が効果的に根絶され、Response.Redirect（...）は完全に信頼できるものになります。さらにテストで別のことが示された場合は、ここで報告しますが、これを環境で停止させるには、セッション状態をSqlServerに移動します（または「InProcから」で十分ですか？わかりません）。

于 2010-11-22T16:05:48.250 に答える
0

アプリケーション プールのリサイクルにより、セッションが失われる可能性があります。一定の時間 (推奨、夜間または使用率の低い時間帯) にリサイクルするようにアプリ プールを構成するか、アプリ プールのリサイクルのタイムアウト期間を長くすることができます。

于 2010-02-15T21:26:29.197 に答える