To upgrade from Asp.ne T 1.1 to ASP.net 2.0 cookie issues to consider

asp.net|cookie| problem

When you are ready 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 fail.

Blog Park also encountered such a problem, for the blog, meaning that all users of cookies need to login, although this is not a big problem, but it does bring trouble to everyone, if forgotten the password, will be more trouble.

For a site that attaches great importance to customer satisfaction, it should try to solve the problem. The blog Park wants to minimize the impact of the upgrade, so I've been working on the problem for two days and found a solution.

The problem is that when the program is upgraded from ASP.net 1.1 to asp.net 2.0, asp.net 2.0 decrypts the cookie sent by the client using the new algorithm and the key, causing the cookie generated in asp.net to asp.net 2.0 in the failure. In ASP.net 1.1, the content of the cookie is encrypted using the 3DES algorithm, and the Advanced Encrypted Standards (AES) algorithm is used by default in ASP.net 2.0 to decrypt it, which is one of the causes of the problem. With the appropriate settings, you can change the cookie encryption algorithm to 3DES in asp.net 2.0, simply add the following: <machinekey decryption= "3DES"/>. But after doing so, the problem persists because the same key is required in addition to the same algorithm for decryption. If the key is not specified in machinekey, asp.net 2.0 uses the randomly generated key by default, which is System.Web.HttpRuntime.SetAutogenKeys () with the secret key. Generated and stored in System.Web.HttpRuntime.s_autogenKeys, you can get this value by reflection. The machinekey of ASP.net 1.1 is set in Machine.config, and the following secret key is used by default:

<machinekey validationkey= "Autogenerate,isolateapps" decryptionkey= Autogenerate,isolateapps "validation=" SHA1 "/>.

The problem is on a different random key. If you have specified the key in the original ASP.net 1.1, then there is no such problem, but it is generally considered when using Web farm. So it is usually the case that the random key is used. Asp. NET generates different random keys for different applications, and this client cookie failure problem can occur in many cases, such as reloading the system, moving the ASP.net application to another computer, moving the Web application to a different virtual directory, and so on.

How to solve this problem?

The principle is simple, as long as we know the value of the key randomly generated in ASP.net 1.1, and then the ASP.net 2.0 The web.config of the application is specified, there are two keys: one is the encryption key decryptionkey, and the other is the hash key validationkey (to prevent the cookie from being tampered in midstream). If we know that the key is: X, Y, then the web.config
The following settings will solve the problem:

<machinekey validationkey= "X" decryptionkey= "Y" decryption= "3DES"/>

The problem is how to get the value of a randomly generated key in ASP.net 1.1. The key was stored in the LSA (Windows Local Security Authority), but I didn't find a way to get the key from the LSA.

As the blog park is mainly to solve the problem of login cookies, and this cookie is in System.Web.Security.FormsAuthentication. SetAuthCookie (string userName, bool createPersistentCookie), so I'm going to go from asp.net 1.1 of System.Web.Security.FormsAuthentication's source code, found System.Web.Configuration.MachineKey, after further research on MachineKey source code, in Machin In the machinekeyconfig of Ekey, two keys were found in the private static members of S_validationkey and S_odes (which was found to be a lot of effort), and validationkey values were stored directly in S_ ValidationKey, while DecryptionKey is stored in S_odes.key. Because machinekey is a internal class,machinekeyconfig is a private type, that two members are private static members, which cannot be accessed directly. At this point, it is. NET in the powerful reflection function of the time to play a role. By reflecting these two values, it is worth noting that the type of the two values is byte[] and that the test found that the key generated by the direct conversion to the string is invalid. You need to convert System.Web.Configuration.MachineKey.ByteArrayToHexString (byte[], Int32) to a string by reflection.

This evening finally solved the problem, so excited! Halfway want to give up, but think in the blog Park program upgrade to ASP.net 2.0, because this problem to a lot of people bring trouble, although only need to log in once on the line, but I still think to solve this problem, do the program development is to bring convenience to the user as far as possible?

Solve this problem for the blog Park site to upgrade to ASP.net 2.0 for further preparation.