Web アプリケーションを ASP.NET 1.1 から ASP.NET 2.0 にアップグレードする準備をするときに、Cookie の問題に直面します。クライアントによって ASP.NET 1.1 アプリケーションに保存されたすべての Cookie が無効になります。
Blog Park では、Cookie を使用するすべてのユーザーが再度ログインする必要があるため、大きな問題ではありませんが、パスワードを忘れると、すべての人に迷惑がかかります。もっと面倒です。
ユーザー満足度を重視するWebサイトでは、この問題を解決する努力が必要です。 Blog Park では、アップグレードによる影響をできる限り軽減したいと考えており、この 2 日間この問題を調査し、解決策を見つけました。
問題の原因は、プログラムが ASP.NET 1.1 から ASP.NET 2.0 にアップグレードされるときに、ASP.NET 2.0 が新しいアルゴリズムとキーを使用してクライアントから送信された Cookie を復号化し、その結果 Cookie が無効になることです。 ASP.NET 2.0。 ASP.NET 1.1 では、Cookie のコンテンツの暗号化に 3DES アルゴリズムが使用されますが、ASP.NET 2.0 では、暗号化解除にデフォルトで Advanced Encrypted Standards (AES) アルゴリズムが使用されます。これが問題の原因の 1 つです。対応する設定を使用して、ASP.NET 2.0 の Cookie 暗号化アルゴリズムを 3DES に変更するには、<machineKey decryption="3DES"/> を web.config に追加するだけです。しかし、これを実行した後でも、復号化には同じアルゴリズムに加えて同じキーも必要となるため、問題は依然として存在します。 machineKey にキーが指定されていない場合、ASP.NET 2.0 はデフォルトでランダムに生成されたキーを使用します。このランダム キーは System.Web.HttpRuntime.SetAutogenKeys() によって生成され、System.Web.HttpRuntime.s_autogenKeys に保存されます。この値は反射によって得られます。 ASP.NET 1.1 の machineKey は machine.config で設定され、ランダム キーもデフォルトで使用されます。
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>。
問題は、異なるランダムキーにあります。オリジナルの ASP.NET 1.1 でキーを指定した場合、この問題は発生しませんが、これは Web ファームを使用する場合に一般に考慮されます。したがって、通常はランダムなキーが使用されます。 ASP.NET は、アプリケーションごとに異なるランダム キーを生成します。このクライアント Cookie エラーの問題は、システムの再インストール、ASP.NET アプリケーションの別のコンピュータへの移動、Web アプリケーションの別の仮想ディレクトリへの移動など、さまざまな状況で発生します。等々。
この問題を解決するにはどうすればよいでしょうか?
原理は非常に簡単です。ASP.NET 1.1 でランダムに生成されたキーの値がわかっていて、それを ASP.NET 2.0 アプリケーションの web.config で指定する限りです。ここには 2 つのキーがあります。1 つは暗号化です。キーdecryptionKey、1つはハッシュ計算キーvalidationKey（Cookieが途中で改ざんされるのを防ぐため）です。キーが X と Y であることがわかっている場合は、web.config で
この問題は、次の設定を行うことで解決できます。
<machineKey validationKey="X" decryptionKey="Y" decryption="3DES"/>
問題は、ASP.NET 1.1 でランダムに生成されたキーの値を取得する方法です。キーは LSA (Windows Local Security Authority) に保存されていますが、LSA からキーを取得する方法が見つかりませんでした。
Blog Park は主にログイン Cookie の問題を解決するもので、この Cookie は System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie) で生成されるため、ASP.NET 1.1 の System.Web.Security から開始しました。 .FormsAuthentication のソース コードで、System.Web.Configuration.MachineKey を発見しました。MachineKey のソース コードをさらに調査した結果、MachineKey の MachineKeyConfig に 2 つのキーが見つかりました。これらは s_validationKey と s_oDes の 2 つのプライベート静的メンバーに存在します。これを発見するには多大な労力がかかりました)、validationKey の値は s_validationKey に直接格納され、decryptionKey は s_oDes.Key に格納されます。 MachineKey は内部クラスであり、MachineKeyConfig はプライベート型であるため、これら 2 つのメンバーはプライベート静的メンバーであり、直接アクセスできません。このとき、.NET の強力なリフレクション機能が活躍します。これら 2 つの値はリフレクションによって取得されます。ただし、これら 2 つの値の型は Byte[] であり、文字列に直接変換して生成されたキーは無効であることがわかります。文字列に変換されたリフレクション (Byte[], Int32) を通じて System.Web.Configuration.MachineKey.ByteArrayToHexString を呼び出す必要があります。
今夜ついにこの問題を解決できたので、とても興奮しています!途中で何度も諦めようと思ったのですが、ブログパークプログラムをASP.NET 2.0にバージョンアップした後、この問題が多くの方にご迷惑をおかけすることになるだろうと思い、再度ログインするだけで済みましたが、今でもそう感じています。この問題を解決し、プログラムの開発はユーザーの利便性を最大限に高めるものではないでしょうか。
この問題を解決すると、Blog Park Web サイトを ASP.NET 2.0 にアップグレードするための準備がさらに整います。
出典: dudu-happy プログラマー