Единый знак cookie, удаленный антишпионским программным обеспечением

Question

У нас есть единый знак реализации для семейства веб-сайтов, в которых cookie-файлы аутентификации поступают из корневого домена (например, bar.com), что позволяет им входить в дочерний домен (например, foo.bar.com). Реализация в C # с использованием стандартной аутентификации форм .net.

К сожалению, некоторые из наших пользователей удаляют свои файлы cookie аутентификации антишпионским программным обеспечением. Мне удалось воссоздать эту ситуацию с помощью PC Tools Anti Spyware и IE8.

Практическим результатом является то, что пользователи заходят на сайт, переходят на другую страницу, а затем их просят войти снова.

Антишпионское программное обеспечение помечает cookie как файл отслеживания с низким уровнем риска.

Есть ли какой-нибудь способ сделать печенье более приемлемым для явно привередливых вкусов антишпионского программного обеспечения нашего пользователя?

Обновление:

Я заглянул в ведущий "." вопрос, и это красная сельдь. IE не волнует и, как я узнал по в этом посте , спецификация RFC 2965 требует, чтобы разработчики указывали начальную точку.

Дальнейшее чтение привело меня к статье «Предупреждение о конфиденциальности: варианты cookie могут использоваться для блокирования блокировщиков, средств защиты от шпионских программ» . По сути, многие веб-сайты используют субдомены как способ скрытия файлов cookie для отслеживания.

Похоже, что некоторые антишпионские программы будут соблюдать P3P (Платформа для настроек конфиденциальности) декларации в родительском домене. К сожалению, из-за отсутствия поддержки со стороны разработчиков браузеров работа на P3P была приостановлена.

На этом этапе я думаю, что решение проблемы будет таким, как предложил один пользователь: субдомен должен будет создать свой собственный файл cookie аутентификации.

Answer 1

Вы можете изучить транспорты по умолчанию в спецификациях протокола SSL SAML, чтобы получить больше идей. Архив всех документов находится здесь возможные транспорты (в частности, при перенаправлении и POST).

Распространенной идеей является запрос сервера SSO, если текущий пользователь прошел проверку подлинности, а затем кеширование этого состояния с помощью собственного cookie. Таким образом, каждое приложение устанавливает только куки на своем домене.

Answer 2

Я построил такую ​​систему. Существует один домен, который выполняет вход (авторизация сайта). Если вход в систему успешен, он перенаправляет пользователя с сайта авторизации на сайт, который инициировал вход в систему с помощью одного токена. Тогда этот сайт устанавливает свой собственный cookie и качает вашего дядю. Когда вы выходите из системы, вы должны перейти непосредственно на сайт авторизации, который удаляет cookie как часть перенаправления обратно на сайт. Затем ваш сайт удаляет свой собственный файл cookie. Хахаха, надеюсь, это имеет смысл!

Answer 3

Вы можете проверить, что ваш файл cookie авторизации использует домен .bar.com, который должен работать на www.bar.com, foo.bar.com, etc.bar.com.

Это точное поведение зависит от браузера, но это обычная практика, позволяющая использовать один и тот же файл cookie в нескольких поддоменах. Обратите внимание, что если ваш файл cookie для аутентификации изначально установлен на www.bar.com, то хороший браузер должен отклонить его для foo.bar.com, но не для foo.www.bar.com

Имею ли я какой-то смысл? : -)

Обновление: Похоже, вы можете переопределить domain в разделе <forms вашего Web.config, вот ссылка . Я бы начал там.