Cookie issues to be considered when upgrading from ASP. NET 1.1 to ASP. NET 2.0

When you want to extract the web application from ASP. NET 1.1 upgrade to ASP. NET 2.0, you will face such a cookie problem: in ASP. all cookies saved by the client in the. NET 1.1 application will become invalid.
The blog Park has encountered such a problem. For the blog park, it means that all users who use Cookies need to log on again. Although this is not a big problem, but it does bring you trouble. If you forget your password, it will be even more troublesome.
For a website that attaches great importance to user satisfaction, efforts should be made to solve this problem. Blog hope to minimize the impact of the upgrade, so I have been studying this problem and found a solution for the past two days.
The cause of the problem is: when the program starts from ASP. NET 1.1 upgraded to ASP. after the NET 2.0, Asp.. NET 2.0 uses the new algorithm and key to decrypt the cookie sent from the client. the cookie generated in. NET is stored in ASP.. NET 2.0 is invalid. In ASP. in. NET 1.1, the 3DES algorithm is used to encrypt the cookie content. NET 2.0 uses the advanced encrypted standards (AES) algorithm by default for decryption, which is one of the reasons for the problem. You can set the ASP. in NET 2.0, the cookie encryption algorithm is changed to 3DES. add :. however, after this operation, the problem still exists, because in addition to the same algorithm, the same key is required for decryption. If the key is not specified in machinekey, Asp. NET 2.0 uses a random key by default. web. httpruntime. setautogenkeys () is generated and stored in system. web. httpruntime. in s_autogenkeys, you can obtain this value through reflection. The machinekey of ASP. NET 1.1 is set in machine. config, and the random key is used by default:. The problem lies in different random keys. If you specify a key in the original ASP. NET 1.1, this problem does not exist. However, this issue is generally considered when you use web farm. Therefore, random keys are usually used. ASP. net will generate different random keys for different applications. This client cookie failure problem may occur in many situations, such as: reinstalling the system.. NET application to another computer, and Web applications to different virtual directories.
How can this problem be solved?
The principle is very simple, as long as we know in ASP. NET 1.1, and then in ASP. NET 2.0 application web. you can specify the key in config. Here, there are two keys: one is the encryption key decryptionkey and the other is the hash calculation key validationkey (to prevent cookie tampering in the middle ). If we know that the keys are X and Y, they are stored on the web. you can solve the problem by setting the following configuration: the difficulty lies in how to obtain ASP.. NET 1.1. The key is stored in LSA (Windows Local Security Authority), but I have not found a way to obtain the key from LSA.
Because the main cause of the blog is to solve the login cookie problem, and the cookie is in the system. web. security. formsauthentication. setauthcookie (string username, bool createpersistentcookie. NET 1.1 system. web. security. formsauthentication source code, found the system. web. configuration. machinekey, after further research on the source code of the machinekey, in machinekeyconfig of machinekey, the two keys are found in the Private Static members s_validationkey and s_odes (this is a lot of work). The values of validationkey are directly stored in s_validationkey, and decryptionke Y is stored in s_odes.key. Since machinekey is an internal class and machinekeyconfig is a private type, the two members are private static members and cannot be directly accessed. In this case, yes. Net. The two values are obtained through reflection. Note that the two values belong to the byte [] type. Test results show that the key generated by directly converting to a string is invalid. You need to call system through reflection. web. configuration. machinekey. bytearraytohexstring (byte [], int32) is converted to a string.
I finally solved this problem this evening. I'm so excited! I want to give up several times in the middle, but I want to upgrade my blog garden program to ASP. NET 2.0 may cause problems for many people. Although you only need to log on again, I still think it is necessary to solve this problem, isn't program development as convenient as possible for users?
After this problem is solved, we have made further preparations for upgrading the blog site to ASP. NET 2.0.
Source: webmaster-http://www.master8.net/data/2007/0529/article_8185.htm