Asp.NetのForms検証、CookieとSeesionの失効時間の解決
16607 ワード
ウェブサイト開発におけるユーザ認証は一般的にAspを採用する.NetのForms検証、検証手形がCookieに格納される方法.
Session方式は検証情報をメモリに格納することであり、もしあなたが使用している仮想ホストがあなたに小さなメモリを割り当てている場合、実際にはそうであれば、sessionはすぐに期限切れになり、再ログインを要求し、ユーザーが情報を記入している場合、再ログインを要求されている場合、怒りの感じがわかります.
クッキーはユーザのクライアントに格納されている.しかし、失効の問題にも遭遇し、次のように理解します.
ASP.NET Forms検証では、通常ASPを使用します.NETが持参したLoginコントロールで検証を行います.同時に、web.configファイルでは、すべてのForms設定をデフォルトに設定します.今、問題が来ました.
1.どうして私は「Remember me」を注文したのに、30分ぐらい後にまたLogoutしたの?
2.なぜ私はtimeoutを無期限e.g.400000に設定したのに、どうして1、2日後にまたLogoutしたのですか.
これはForms検証で多くの問題に遭遇したものです.次に、私はこの2つの問題について詳しく説明します.問題1について、まずticketとcookieの違いを説明します.クッキーはクライアントに保存されている容器です.ticketは、クッキーという容器に置かれた具体的な検証情報を表すための具体的なデータです.そこで、私たちが検証する過程で、以下のことが起こりました.まずticketは作成され、ユーザー名などの情報が含まれていると同時に、期限切れがあります.
そして、クッキーが作られ、同じように期限が切れています.最後にticketをクッキーに保存し、クライアントのブラウザに送信します.ここまで読んで、問題はもうよく分かったと思いますが、ユーザーのログアウトは時間が切れた問題のためです.しかし、具体的には誰の時間が期限切れになったのでしょうか.私たちのASP.NET web.configの設定では、timeoutはクッキーの期限切れ(デフォルトは30分)であり、ticketの期限切れは無限である.それが私が「Remember me」を注文した理由です.
しかし、30分ほど後、私はまだログアウトされました.私たちはクッキーのtimeoutを設定していないからです.ticketとcookieは、そのうちの1つが永遠に期限切れでない限り、私たちは永遠に期限切れにならないことを実現することはできません.
問題を解決した後(timeout=「4000,000」を手動で設定した場合)、また問題2に遭遇しました.これはまた何の原因ですか?これはticketの暗号解読メカニズムから話さなければならない.ASP.NETでは、アプリケーションの起動時にランダムに生成されるmachinekeyを使用してクッキーを暗号化します.そして、ASP.NETは同じmachinekeyを使用してクッキーを復号します.このkeyはアプリケーションの起動時にランダムに生成されるので問題2になります.アプリケーションrecycle(再起動)したらどうする?
ASP.NETは別のキーを生成して復号し、以前のクッキーは有効ではないことが問題2の原因です.これを知って、2つ目の問題を解決する方法は簡単で、手動で特定のkeyを設定します.例えば、
Aspを実現する.NetForms認証の操作手順
アプリケーションの認証については、ログインフォームを作成してから、フォームのCSファイルでユーザーのログインが正当かどうかを判断し、正当であればユーザー名をCookieに保存します.その後、すべてのページをBaseFormのようなベースページに継承し、このページのPage_Loadイベントには,Cookieによりユーザがログインしているか否かを判定し,ログインしていない場合はログインページに遷移する判定が加わる.最近、インタネットサイトを作って、セキュリティの問題を思い出して、いくつかの資料を調べてからAspを採用したと思います.Netが提供する標準的なForms検証方式.研究してみると、今から操作手順を書いて、後で使うときに参考にする(ブログの現在の重要な機能の一つは、かつての学習の蓄積を保存することである)1、webを修正することである.configファイル.vs 2005の場合、デフォルトではこのファイルがなく、デバッグ時にファイルを追加するかどうかをプロンプトされます.Webでconfigファイルのセクションには、次の3つのセクションが追加されます.
上の3つの部分にはそれぞれ異なる色が表示されています.第1の部分はアプリケーションの認証モードを設定し、デフォルトはwindowsです.もしあなたのシステムがローカルエリアネットワーク内で使用され、ローカルエリアネットワーク全体がドメインモードで動作している場合、windowsの認証方式は良い効果があります.複数のB/Sがwindowsモードで認証を行うと、彼らは非常に便利に単一のログインの効果を実現することができます.しかし、Forms認証はより一般的に使用されています.相対的にセキュリティが悪いという問題がありますが.authenticationセクションの下にformsセクションがあります.そこには、認証を実行するページと、認証に使用されるCookie名を格納することができます.クッキーの名前を記入しないならNetデフォルト割当ASPXFORMMSAUTHはCookie名として使用されます.第2部authorizationはライセンス部分です.アプリケーションへのアクセスを許可または拒否するように構成できます.彼の下にはdeny、allowが使用でき、ワイルドカードを組み合わせることができますか?、*軽量レベルの簡単な認証システムを簡単に構成できます.詳細な構成情報はaspを参照することができる.Netのヘルプドキュメントは、ここでは詳しく説明しません.第3部machineKeyは、Cookieへのアクセスを構成するために用いられる暗号化/復号アルゴリズムである.このアルゴリズムがあれば、Cookieは比較的安全なのではないでしょうか.2、クッキー情報を登録して保存する.
まず、ユーザーの名前、Cookieの期限切れを主に保存するアイデンティティ手形を作成します.また、ユーザーが果たす役割など、追加のデータを保存することもできます.ここで注意したいのは、UserDataはロールなどの追加データを保存するために使用されますが、私がデータを持っていない場合は、通常null値を送信しますが、Cookie情報を暗号化して保存したい場合は、null値を送信することはできません.「」値を送信することができます.null値を渡すとstring encryptedTicket=FormsAuthenticationが実行されます.Encrypt(authTicket); するとnull値が返され、暗号化Cookie値が誤って生成されます.Cookieを長期保存する場合は、Cookieの有効期限を設定する必要があります.3、コンピュータに保存されているCookieを読み込みます.GlobalでasaxファイルにApplication_が存在するAuthenticateRequestイベントは、すべてのサーバ側リクエストを実行するときに実行されます.そのため、この場所でCookieを読み取り、復号することができます.サンプルコードは次のとおりです.
Cookieを暗号化して保存した後、復号してから使用する必要があります.4.各ページにCookieの値を読み込む.Cookieの値は次の文で読み取ることができます.HttpContext.Current.User.Identity.Name
本文はCSDNブログから来て、転載して出典を明記してください:http://blog.csdn.net/vasun/archive/2009/12/29/5100743.aspx
Session方式は検証情報をメモリに格納することであり、もしあなたが使用している仮想ホストがあなたに小さなメモリを割り当てている場合、実際にはそうであれば、sessionはすぐに期限切れになり、再ログインを要求し、ユーザーが情報を記入している場合、再ログインを要求されている場合、怒りの感じがわかります.
クッキーはユーザのクライアントに格納されている.しかし、失効の問題にも遭遇し、次のように理解します.
ASP.NET Forms検証では、通常ASPを使用します.NETが持参したLoginコントロールで検証を行います.同時に、web.configファイルでは、すべてのForms設定をデフォルトに設定します.今、問題が来ました.
1.どうして私は「Remember me」を注文したのに、30分ぐらい後にまたLogoutしたの?
2.なぜ私はtimeoutを無期限e.g.400000に設定したのに、どうして1、2日後にまたLogoutしたのですか.
これはForms検証で多くの問題に遭遇したものです.次に、私はこの2つの問題について詳しく説明します.問題1について、まずticketとcookieの違いを説明します.クッキーはクライアントに保存されている容器です.ticketは、クッキーという容器に置かれた具体的な検証情報を表すための具体的なデータです.そこで、私たちが検証する過程で、以下のことが起こりました.まずticketは作成され、ユーザー名などの情報が含まれていると同時に、期限切れがあります.
そして、クッキーが作られ、同じように期限が切れています.最後にticketをクッキーに保存し、クライアントのブラウザに送信します.ここまで読んで、問題はもうよく分かったと思いますが、ユーザーのログアウトは時間が切れた問題のためです.しかし、具体的には誰の時間が期限切れになったのでしょうか.私たちのASP.NET web.configの設定では、timeoutはクッキーの期限切れ(デフォルトは30分)であり、ticketの期限切れは無限である.それが私が「Remember me」を注文した理由です.
しかし、30分ほど後、私はまだログアウトされました.私たちはクッキーのtimeoutを設定していないからです.ticketとcookieは、そのうちの1つが永遠に期限切れでない限り、私たちは永遠に期限切れにならないことを実現することはできません.
問題を解決した後(timeout=「4000,000」を手動で設定した場合)、また問題2に遭遇しました.これはまた何の原因ですか?これはticketの暗号解読メカニズムから話さなければならない.ASP.NETでは、アプリケーションの起動時にランダムに生成されるmachinekeyを使用してクッキーを暗号化します.そして、ASP.NETは同じmachinekeyを使用してクッキーを復号します.このkeyはアプリケーションの起動時にランダムに生成されるので問題2になります.アプリケーションrecycle(再起動)したらどうする?
ASP.NETは別のキーを生成して復号し、以前のクッキーは有効ではないことが問題2の原因です.これを知って、2つ目の問題を解決する方法は簡単で、手動で特定のkeyを設定します.例えば、
Aspを実現する.NetForms認証の操作手順
アプリケーションの認証については、ログインフォームを作成してから、フォームのCSファイルでユーザーのログインが正当かどうかを判断し、正当であればユーザー名をCookieに保存します.その後、すべてのページをBaseFormのようなベースページに継承し、このページのPage_Loadイベントには,Cookieによりユーザがログインしているか否かを判定し,ログインしていない場合はログインページに遷移する判定が加わる.最近、インタネットサイトを作って、セキュリティの問題を思い出して、いくつかの資料を調べてからAspを採用したと思います.Netが提供する標準的なForms検証方式.研究してみると、今から操作手順を書いて、後で使うときに参考にする(ブログの現在の重要な機能の一つは、かつての学習の蓄積を保存することである)1、webを修正することである.configファイル.vs 2005の場合、デフォルトではこのファイルがなく、デバッグ時にファイルを追加するかどうかをプロンプトされます.Webでconfigファイルの
<
authentication mode
=
"
Forms
"
>
<
forms loginUrl
=
"
default.aspx
"
name
=
"
.ASPXFORMSAUTH
"
>
</
forms
>
</
authentication
>
<
authorization
>
<
deny users
=
"
?
"
/>
</
authorization
>
<
machineKey
validationKey
=
"
AutoGenerate,IsolateApps
"
decryptionKey
=
"
AutoGenerate,IsolateApps
"
validation
=
"
SHA1
"
decryption
=
"
Auto
"
/>
上の3つの部分にはそれぞれ異なる色が表示されています.第1の部分はアプリケーションの認証モードを設定し、デフォルトはwindowsです.もしあなたのシステムがローカルエリアネットワーク内で使用され、ローカルエリアネットワーク全体がドメインモードで動作している場合、windowsの認証方式は良い効果があります.複数のB/Sがwindowsモードで認証を行うと、彼らは非常に便利に単一のログインの効果を実現することができます.しかし、Forms認証はより一般的に使用されています.相対的にセキュリティが悪いという問題がありますが.authenticationセクションの下にformsセクションがあります.そこには、認証を実行するページと、認証に使用されるCookie名を格納することができます.クッキーの名前を記入しないならNetデフォルト割当ASPXFORMMSAUTHはCookie名として使用されます.第2部authorizationはライセンス部分です.アプリケーションへのアクセスを許可または拒否するように構成できます.彼の下にはdeny、allowが使用でき、ワイルドカードを組み合わせることができますか?、*軽量レベルの簡単な認証システムを簡単に構成できます.詳細な構成情報はaspを参照することができる.Netのヘルプドキュメントは、ここでは詳しく説明しません.第3部machineKeyは、Cookieへのアクセスを構成するために用いられる暗号化/復号アルゴリズムである.このアルゴリズムがあれば、Cookieは比較的安全なのではないでしょうか.2、クッキー情報を登録して保存する.
FormsAuthenticationTicket authTicket
=
new
FormsAuthenticationTicket(
1
,CookieInfo,
DateTime.Now, DateTime.Now.AddHours(
20
),
false
,UserData);
//
User data
string
encryptedTicket
=
FormsAuthentication.Encrypt(authTicket);
//
//
Cookie
HttpCookie authCookie
=
new
HttpCookie(FormsAuthentication.FormsCookieName,
encryptedTicket);
authCookie.Expires
=
authTicket.Expiration;
Response.Cookies.Add(authCookie);
まず、ユーザーの名前、Cookieの期限切れを主に保存するアイデンティティ手形を作成します.また、ユーザーが果たす役割など、追加のデータを保存することもできます.ここで注意したいのは、UserDataはロールなどの追加データを保存するために使用されますが、私がデータを持っていない場合は、通常null値を送信しますが、Cookie情報を暗号化して保存したい場合は、null値を送信することはできません.「」値を送信することができます.null値を渡すとstring encryptedTicket=FormsAuthenticationが実行されます.Encrypt(authTicket); するとnull値が返され、暗号化Cookie値が誤って生成されます.Cookieを長期保存する場合は、Cookieの有効期限を設定する必要があります.3、コンピュータに保存されているCookieを読み込みます.GlobalでasaxファイルにApplication_が存在するAuthenticateRequestイベントは、すべてのサーバ側リクエストを実行するときに実行されます.そのため、この場所でCookieを読み取り、復号することができます.サンプルコードは次のとおりです.
1
protected
void
Application_AuthenticateRequest(
object
sender, EventArgs e)
2
{
3
string
cookieName
=
FormsAuthentication.FormsCookieName;
//
Cookie 。
4
//
Cookie.
5
HttpCookie authCookie
=
Context.Request.Cookies[cookieName];
6
if
(
null
==
authCookie)
7
return
;
8
FormsAuthenticationTicket authTicket
=
null
;
9
//
。
10
authTicket
=
FormsAuthentication.Decrypt(authCookie.Value);
11
if
(
null
==
authTicket)
12
return
;
13
14
//
UserData 。
15
//
UserData 。 。
16
string
[] roles
=
authTicket.UserData.Split(
new
char
[] {
'
,
'
});
17
FormsIdentity id
=
new
FormsIdentity(authTicket);
18
GenericPrincipal principal
=
new
GenericPrincipal(id, roles);
19
//
．
20
Context.User
=
principal;
21
}
Cookieを暗号化して保存した後、復号してから使用する必要があります.4.各ページにCookieの値を読み込む.Cookieの値は次の文で読み取ることができます.HttpContext.Current.User.Identity.Name
本文はCSDNブログから来て、転載して出典を明記してください:http://blog.csdn.net/vasun/archive/2009/12/29/5100743.aspx