Единый знак cookie, удаленный антишпионским программным обеспечением
У нас есть единый знак реализации для семейства веб-сайтов, в которых cookie-файлы аутентификации поступают из корневого домена (например, bar.com), что позволяет им входить в дочерний домен (например, foo.bar.com). Реализация в C# с использованием стандартной аутентификации форм.net.
К сожалению, некоторые из наших пользователей удаляют свои файлы cookie аутентификации антишпионским программным обеспечением. Я смог воссоздать эту ситуацию с помощью PC Tools Anti Spyware и IE8.
Практический результат заключается в том, что пользователи заходят на сайт, переходят на другую страницу, а затем их просят войти снова.
Анти-шпионское программное обеспечение помечает cookie как файлы cookie для отслеживания с низким уровнем риска.
Есть ли какой-нибудь способ сделать печенье более приемлемым для явно привередливых вкусов антишпионского программного обеспечения нашего пользователя?
Обновить:
Я посмотрел в ведущих "." вопрос и это красная сельдь. IE не волнует, и, как я узнал из этого поста, спецификация RFC 2965 требует, чтобы разработчики поставляли ведущую точку.
Дальнейшее чтение привело меня к статье "Предупреждение о конфиденциальности: варианты cookie можно использовать для блокирования блокировщиков, средств защиты от шпионских программ". По сути, многие веб-сайты используют субдомены как способ скрытия файлов cookie отслеживания.
Похоже, что некоторые антишпионские программы будут соблюдать декларации P3P (Platform for Privacy Preferences) в родительском домене. К сожалению, из-за отсутствия поддержки со стороны разработчиков браузеров работа над P3P была приостановлена.
На этом этапе я думаю, что решение проблемы будет таким, как предложил один пользователь: субдомен должен будет создать свой собственный куки-файл аутентификации.
3 ответа
Я построил такую систему. Существует один домен, который выполняет вход (авторизация сайта). Если вход в систему успешен, он перенаправляет пользователя с сайта авторизации на сайт, который инициировал вход в систему с помощью одного токена. Затем этот сайт устанавливает свой собственный cookie и качает вашего дяди. Когда вы выходите из системы, вы должны перейти непосредственно на сайт авторизации, который удаляет cookie как часть перенаправления обратно на сайт. Затем ваш сайт удаляет свой собственный файл cookie. Хахаха, надеюсь, это имеет смысл!
Вы можете изучить транспорт по умолчанию в спецификациях протокола SSL SAML, чтобы получить больше идей. Архив со всеми документами находится здесь http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip Смотрите "Утверждения и протоколы" для описания протокола и "Привязки" для возможных переносов. (в частности при перенаправлении и POST).
Общая идея заключается в том, чтобы как-то запросить сервер SSO, если текущий пользователь прошел проверку подлинности, и затем кэшировать этот статус с помощью собственного cookie. Таким образом, каждое приложение устанавливает только куки на своем домене.
Вы можете проверить, что ваш файл 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, вот ссылка. Я бы начал там.