Когда вы готовитесь обновить свое веб-приложение с ASP.NET 1.1 до ASP.NET 2.0, вы столкнетесь с проблемой файлов cookie: все файлы cookie, сохраненные клиентом в приложении ASP.NET 1.1, станут недействительными.
Blog Park также столкнулся с такой проблемой. Для Blog Park это означает, что всем пользователям, использующим файлы cookie, необходимо снова войти в систему. Хотя это не большая проблема, но если вы забудете свой пароль, это принесет неприятности. более хлопотно.
Для веб-сайта, который придает большое значение удовлетворению пользователей, следует приложить усилия для решения этой проблемы. Блог Парк надеется максимально снизить влияние обновления, поэтому я изучал эту проблему последние два дня и нашел решение.
Причина проблемы: при обновлении программы с ASP.NET 1.1 до ASP.NET 2.0 ASP.NET 2.0 использует новый алгоритм и ключ для расшифровки файла cookie, отправленного клиентом, в результате чего файлы cookie становятся недействительными в АСП.НЕТ 2.0. В ASP.NET 1.1 для шифрования содержимого файла cookie используется алгоритм 3DES, а в ASP.NET 2.0 для расшифровки по умолчанию используется алгоритм Advanced Encrypted Standards (AES). Это одна из причин проблемы. Вы можете использовать соответствующие настройки, чтобы изменить алгоритм шифрования файлов cookie в ASP.NET 2.0 на 3DES, просто добавьте: <machineKey decryption="3DES"/> в файл web.config. Но после этого проблема все равно существует, поскольку для расшифровки помимо того же алгоритма требуется еще и тот же ключ. Если в MachineKey не указан ключ, ASP.NET 2.0 по умолчанию будет использовать случайно сгенерированный ключ. Этот случайный ключ генерируется с помощью System.Web.HttpRuntime.SetAutogenKeys() и сохраняется в System.Web.HttpRuntime.s_autogenKeys. Вы можете получить. эту ценность через размышление. MachineKey ASP.NET 1.1 установлен в файле Machine.config, по умолчанию также используется случайный ключ:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
Проблема заключается в разных случайных ключах. Если бы вы указали ключ в исходной версии ASP.NET 1.1, этой проблемы не было бы, но обычно это учитывается при использовании веб-ферм. Поэтому обычно используется случайный ключ. ASP.NET будет генерировать разные случайные ключи для разных приложений. Эта проблема сбоя cookie-файла клиента возникает во многих ситуациях, таких как: переустановка системы, перемещение приложения ASP.NET на другой компьютер, веб-приложение перемещается в другой виртуальный каталог. и так далее.
Как решить эту проблему?
Принцип очень прост: мы знаем значение случайно сгенерированного ключа в ASP.NET 1.1, а затем указываем его в web.config приложения ASP.NET 2.0. Здесь есть два ключа: один — шифрование. Ключ decryptionKey, один из которых является ключом вычисления хэша validationKey (чтобы предотвратить подделку файла cookie на полпути). Если мы знаем, что ключи: X и Y, то в web.config
Проблему можно решить, выполнив следующие настройки:
<machineKey validationKey="X" decryptionKey="Y" decryption="3DES"/>
Проблема в том, как получить значение случайно сгенерированного ключа в ASP.NET 1.1. Ключ хранится в LSA (локальном органе безопасности Windows), но я не нашел способа получить ключ из LSA.
Поскольку парк блогов в основном решает проблему файлов cookie для входа, и этот файл cookie генерируется в System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie), поэтому я начал с System.Web.Security из ASP.NET 1.1. с исходным кодом .FormsAuthentication я обнаружил System.Web.Configuration.MachineKey. После дальнейшего исследования исходного кода MachineKey я нашел два ключа в MachineKeyConfig MachineKey, которые существуют в двух частных статических членах s_validationKey и s_oDes. Чтобы это обнаружить, потребовалось немало усилий), значение validationKey хранится непосредственно в s_validationKey, а decryptionKey — в s_oDes.Key. Поскольку MachineKey является внутренним классом, а MachineKeyConfig — частным типом, эти два члена являются частными статическими членами и к ним нельзя получить прямой доступ. Сейчас пришло время вступить в игру мощной функции отражения в .NET. Эти два значения получены посредством отражения. Следует отметить, что тип этих двух значений — Byte[]. В ходе тестирования обнаружено, что ключ, сгенерированный путем прямого преобразования его в строку, недействителен. Вам нужно вызвать System.Web.Configuration.MachineKey.ByteArrayToHexString через отражение (Byte[], Int32), преобразованное в строку.
Сегодня вечером я наконец решил эту проблему, так взволнован! Я несколько раз хотел сдаться на середине, но подумал, что после обновления программы блог-парка до ASP.NET 2.0 эта проблема вызовет проблемы у многих людей. Хотя мне нужно только снова войти в систему, я все еще чувствую это. Мне нужно решить эту проблему, и разве разработка программы не призвана обеспечить максимальное удобство для пользователей?
Решение этой проблемы позволит провести дальнейшую подготовку к обновлению веб-сайта Blog Park до ASP.NET 2.0.
Источник: dudu-happy программист