When you prepare to upgrade your web application from ASP.NET 1.1 to ASP.NET 2.0, you will face a cookie problem: all cookies saved by the client in the ASP.NET 1.1 application will become invalid.
Blog Park has also encountered such a problem. For Blog Park, it means that all users who use cookies need to log in again. Although this is not a big problem, it does bring trouble to everyone. If you forget your password, will be more troublesome.
For a website that attaches great importance to user satisfaction, efforts should be made to solve this problem. Blog Park hopes to reduce the impact of the upgrade as much as possible, so I have been studying this problem for the past two days and found a solution.
The cause of the problem is: when the program is upgraded from ASP.NET 1.1 to ASP.NET 2.0, ASP.NET 2.0 uses a new algorithm and key to decrypt the cookie sent by the client, which results in the Cookies are invalid in ASP.NET 2.0. In ASP.NET 1.1, the 3DES algorithm is used to encrypt the content of the cookie, while in ASP.NET 2.0, the Advanced Encrypted Standards (AES) algorithm is used by default to decrypt. This is one of the causes of the problem. You can use the corresponding settings to To change the cookie encryption algorithm in ASP.NET 2.0 to 3DES, just add: <machineKey decryption="3DES"/> to web.config. But after doing this, the problem still exists, because in addition to the same algorithm, the same key is also required for decryption. If no key is specified in machineKey, ASP.NET 2.0 will use a randomly generated key by default. This random key is generated by System.Web.HttpRuntime.SetAutogenKeys() and stored in System.Web.HttpRuntime.s_autogenKeys. You can get this value through reflection. The machineKey of ASP.NET 1.1 is set in machine.config, and a random key is also used by default:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
The problem lies in the different random keys. If you specified the key in the original ASP.NET 1.1, this problem would not exist, but this is generally considered when using Web farms. So usually a random key is used. ASP.NET will generate different random keys for different applications. This client cookie failure problem will occur in many situations, such as: reinstalling the system, moving the ASP.NET application to another computer, The web application is moved to a different virtual directory and so on.
How to solve this problem?
The principle is very simple, as long as we know the value of the randomly generated key in ASP.NET 1.1, and then specify it in the web.config of the ASP.NET 2.0 application. There are two keys here: one is encryption The key decryptionKey, one is the hash calculation key validationKey (to prevent the cookie from being tampered with midway). If we know that the keys are: X and Y, then in web.config
The problem can be solved by making the following settings:
<machineKey validationKey="X" decryptionKey="Y" decryption="3DES"/>
The problem is how to get the value of the randomly generated key in ASP.NET 1.1. The key is stored in the LSA (Windows Local Security Authority), but I didn't find a way to get the key from the LSA.
Since the blog park mainly solves the problem of login cookies, and this cookie is generated in System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie), so I started from System.Web.Security of ASP.NET 1.1 Starting with the source code of .FormsAuthentication, I discovered System.Web.Configuration.MachineKey. After further research on the source code of MachineKey, I found two keys in MachineKey's MachineKeyConfig, which exist in the two private static members of s_validationKey and s_oDes. (It took a lot of effort to discover this), the value of validationKey is stored directly in s_validationKey, and the decryptionKey is stored in s_oDes.Key. Since MachineKey is an internal class and MachineKeyConfig is a private type, those two members are private static members and cannot be accessed directly. At this time, it's time for the powerful reflection function in .NET to come into play. These two values are obtained through reflection. It should be noted that the type of these two values is Byte[]. Through testing, it is found that the key generated by directly converting it into a string is invalid. You need to call System.Web.Configuration.MachineKey.ByteArrayToHexString through reflection. (Byte[], Int32) converted to string.
I finally solved this problem tonight, so excited! I wanted to give up several times in the middle, but I thought that after the blog park program was upgraded to ASP.NET 2.0, this problem would cause trouble to many people. Although I only need to log in again, I still feel that I need to solve this problem and do Isn’t program development meant to bring convenience to users as much as possible?
Solving this problem will make further preparations for upgrading the Blog Park website to ASP.NET 2.0.
Source: dudu-happy programmer