それは非常に些細なことに聞こえるかもしれませんが、私は良い答えを見つけることができませんでした.コール)?
1 つのオプションは、BasePage の Page_PreInit、Global.asax の別の Application_AuthenticateRequest、および Global.asax のさらに別の FormsAuthentication_OnAuthenticate にあります。
ソリューションへのリンクは非常に役立ちます。
パヴェル
それは非常に些細なことに聞こえるかもしれませんが、私は良い答えを見つけることができませんでした.コール)?
1 つのオプションは、BasePage の Page_PreInit、Global.asax の別の Application_AuthenticateRequest、および Global.asax のさらに別の FormsAuthentication_OnAuthenticate にあります。
ソリューションへのリンクは非常に役立ちます。
パヴェル
これに関する決定的な答えへのリンクを見つけることはできませんでしたが、個人的な経験とASP.NET アプリケーション ライフ サイクルを読むことから、Application_BeginRequest が最良の選択肢であると思われます。あなたが説明したシナリオ(アプリケーション固有のチケットをASP.NETフォーム認証チケットに変換する)でこのイベントを使用して、数年間実稼働しているアプリケーションがあります。
Application_AuthenticateRequest とあなたが言及した他のものを使用する際の問題は、作成したフォーム認証 Cookie を使用するには、同じ要求サイクルの後半でコントロールが遅すぎることです。
簡単な例を次に示します。チケットを検証する方法については、カスタム ロジックを入力する必要があります。
protected void Application_BeginRequest(Object sender, EventArgs e)
{
if (!GetRequestHasValidTicket() )
{
string bodyToken = Request.Form["MyTokenName"];
//custom logic to authenticate token
bool tokenIsValid = true;
if (tokenIsValid)
{
System.Web.Security.FormsAuthentication.SetAuthCookie("myusername", false);
}
}
}
private bool GetRequestHasValidTicket()
{
FormsAuthenticationTicket ticket = null;
try
{
ticket = System.Web.Security.FormsAuthentication.Decrypt(Request.Cookies[FormsAuthentication.FormsCookieName].Value);
}
catch { }
return ticket != null;
}
BeginRequest の小さな問題は、Context.User がまだ設定されていないことです。そのため、すべての応答にフォーム認証チケットを追加することを避けるために、有効なチケットを手動で確認する必要があります。アプリケーション ロジックが、チケットが最初のリクエストの本文にのみ表示されるようなものである場合、この追加のチェックは必要ないかもしれません。