Cookie единой точки входа удален программным обеспечением антишпиона
У нас есть реализация единой точки входа для семейства веб-сайтов, куда cookie аутентификации прибывает из корневого домена (например, bar.com), позволяя им быть зарегистрированным в дочерний домен (например, foo.bar.com). Реализация находится в C# с помощью стандартной аутентификации форм .NET.
К сожалению, некоторым нашим пользователям удаляли их cookie аутентификации программным обеспечением антишпиона. Я смог воссоздать эту ситуацию при помощи Антишпиона Инструментов ПК и IE8.
Практический результат - то, что пользователи входят в сайт, перешли к другой странице и затем попросились войти в систему снова.
Cookie отмечается как cookie отслеживания с низким риском программным обеспечением антишпиона.
Там какой-либо путь состоит в том, чтобы сделать cookie более приемлемым к по-видимому довольно придирчивым вкусам программного обеспечения антишпиона нашего пользователя?
Обновление:
Я изучил ведущую "." проблему, и это - отвлекающий маневр. IE не заботится и, как я узнал с помощью этого сообщения, Спецификация RFC 2965 требует, чтобы конструкторы предоставили ведущую точку.
Дополнительные материалы для чтения привели меня к статье "Privacy alert: Cookie variants can be used to skirt blockers, anti-spyware tools". По существу много веб-сайтов используют субдомены в качестве пути, скрывают cookie отслеживания.
Похоже, что некоторое программное обеспечение антишпиона будет уважать P3P (Платформа для Предпочтений Конфиденциальности) объявления по родительскому домену. К сожалению, из-за отсутствия поддержки от конструкторов браузера, работа была приостановлена на P3P.
На данном этапе я думаю, что решение проблемы будет как один предложенный пользователь: субдомен должен будет создать свой собственный cookie аутентификации.
3 ответа
Вы можете проверить, что ваш cookie аутентификации использует домен .bar.com , который должен работать на www.bar.com , foo.bar.com ], и т. Д. Bar.com .
Это точное поведение зависит от браузера, но это обычная практика, позволяющая использовать один и тот же файл cookie для нескольких поддоменов. Обратите внимание: если ваш файл cookie для аутентификации изначально был настроен на www.bar.com , тогда хороший браузер должен отклонить его для foo.bar.com , но не для foo.www.bar. com
Я понимаю? : -)
Обновление: Похоже, вы можете переопределить домен в разделе
Я построил такую систему. Есть один домен, который выполняет вход (auth site). Если вход успешный, он перенаправляет пользователя с auth-сайта на сайт, который инициировал вход, с помощью одноразового токена. Затем этот сайт устанавливает свой собственный cookie и обманывает вашего дядю. Когда вы выходите из системы, вы должны перейти непосредственно на сайт авторизации, который удаляет cookie как часть перенаправления обратно на сайт. Затем ваш сайт удаляет свой собственный файл cookie. Хахаха надеюсь, это имеет смысл!
Вы можете изучить транспорты по умолчанию в спецификациях протокола SSO SAML, чтобы получить больше идей. Архив со всеми документами находится здесь http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip загляните в «Утверждения и протоколы» для описания протокола и «Привязки» для возможных транспортов (в частности при редиректе и POST).
Общая идея состоит в том, чтобы каким-то образом запросить сервер SSO, аутентифицирован ли текущий пользователь, а затем кэшировать этот статус с помощью собственного файла cookie. Таким образом, каждое приложение устанавливает файлы cookie только в собственном домене.