Блог

У меня необычная проблема с WIF. Я должен использовать WIF 3.5 из-за совместимости с .Net 4.0.

Следуя приведенному здесь совету Витторио Берточчи http://www.cloudidentity.com/blog/2010/05/26/your-fedauth-cookies-on-a-diet-issessionmode-true/ Мы установили IsSessionMode = true в WSFederationAuthenticationModule_SecurityTokenValidated, и большую часть времени он работает идеально — мы получаем небольшие токены FedAuth, которые являются указателями на наш токен в нашем кэше памяти.

Однако периодически мы получаем фрагментированные файлы cookie FedAuth, которые содержат полную информацию о токене.

В нашем коде нет очевидного места, где у нас был бы альтернативный путь к коду.

Я не могу найти никаких других примеров этого конкретного несоответствия в Stack Overflow или в каких-либо блогах о WIF в Интернете в целом, поэтому я задаю этот вопрос здесь на случай, если кто-нибудь еще видел эту проблему и решил ее.

Тем временем мы собираемся попробовать настроить так, чтобы мы могли отлаживать с помощью кода WIF, если мы сможем надежно устранить проблему.

Мы обнаружили проблему — IsSessionMode был установлен не в том месте, он должен был быть в SessionSecurityTokenCreated. Похоже, что он устанавливался для каждого экземпляра, а не при инициализации, что означало, что в некоторых обстоятельствах он имел значение по умолчанию true.

Не могли бы вы поделиться файлами cookie другой проверяющей стороны? Тот, который не использует session? Попробуйте явно назвать файлы cookie каждого RP-файла — каждый по-разному.