Мы используем класс FormsAuthentication для передачи зашифрованных токенов между системой Classic ASP и системой .NET.У нас есть COM-компонент (.NET 2), вызываемый системой Classic ASP, и тот же класс, который используется непосредственно в .NET.
Код выглядит примерно так (без жестко заданных значений):
FormsAuthentication.Initialize();
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, "", new DateTime(2011, 1, 1), new DateTime(2012, 1, 1), false, "TEST");
var token = FormsAuthentication.Encrypt(ticket);
Чтобы расшифровать, мы делаем это:
var data = FormsAuthentication.Decrypt("E03519434CB6C157C24B5A1BFE3964537D9B0(SNIP)").UserData;
Обе части в настоящее время работают на одном и том же сервере, однако у нас установлен machineKey, когда эти системы были на разных серверах.Все работает в .NET 3.5 / CLR 2.
Недавно мы обновили .NET-часть системы до .NET 4. Локально, классические ASP работают на другом сервере, поэтому мы сноваУ нас был один и тот же machineKey, установленный на наших локальных машинах (.NET) и на сервере, на котором работает классический ASPОдин и тот же machineKey установлен в 32 + 64-битном v2 machine.configs и в 32 + 64-битном v4 machine.config (примечание: мы запускаем IIS в 32-битном режиме для некоторых устаревших компонентов COM).
Локально, у нас вообще не было проблем с генерированием токенов в системе Classic ASP (COM-компонент, работающей в CLR 2), работающей на наших локальных машинах (.NET 4).Однако, когда мы только начали развертывать это на промежуточном сервере, мы получаем следующую ошибку:
System.Security.Cryptography.CryptographicException: Length of the data to decrypt is invalid.
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Boolean useValidationSymAlgo, Boolean useLegacyMode, IVType ivType)
at System.Web.Security.FormsAuthentication.Decrypt(String encryptedTicket)
at NewMind.Tourism.DMS.Sso2.Sso.GetUserData(String dmsId, String token) in c:\CI\W\DMS-2.4-Release\NewMind.Tourism.DMS.Sso2\Sso.cs:line 131
at NewMind.Tourism.Core.Utils.SsoUtil.GetUserData(String token) in c:\CI\W\DMS-2.4-Release\NewMind.Tourism.Core\Utils\SsoUtil.cs:line 37
at NewMind.Tourism.Core.AuthenticationService.DoSsoLogin(String ssoToken, Action successAction, Action failureAction) in c:\CI\W\DMS-2.4-Release\NewMind.Tourism.Core\AuthenticationService.cs:line 126
Я провел весь день, пытаясь выяснить причину.Я нашел много статей, в которых говорилось об «aspnet: UseLegacyEncryption», которое, похоже, решает проблему для многих, однако, похоже, для нас это не имеет никакого значения.Я создал небольшой тестовый скрипт, который пытается расшифровать два токена, сгенерированных на моем локальном компьютере (один в .NET 2, один в .NET 4), и запустить его в обоих CLR на обеих машинах:
- На моей машине CLR 2 ** Работает **
- На моей машине CLR 4 ** Работает **
- Стадия разъединения, CLR 2 ** Работает **
- Stage Sever, CLR 4 ** Ошибка **
- Stage Sever, CLR 4, aspnet: UseLegacyEncryption = true ** Ошибка **
У меня закончились идеи,Я не совсем уверен, что попробовать.Ключи машины все идентичны, я трижды проверил.Опция UserLegacyEncryption, похоже, не имеет значения.Я не могу сравнить токены, сгенерированные на каждой машине / CLR, потому что они каждый раз разные.Мы понятия не имеем, почему точно такой же код работает на точно такой же версии .NET Framework на наших компьютерах разработчиков.
Наши планы резервного копирования - создать версию COM-компонента CLR 4 или изменить шифрование.полностью, но нам бы очень хотелось просто понять проблему и решить ее.