По-видимому, IE10 обрабатывает файлы cookie и субдомены по-другому, чем другие основные браузеры (IE8, IE9, Firefox, Chrome, Safari).
Мы широко используем субдомены для тестовых сред, например:
И наша производственная среда живет наверху, например example.com (и технически также на www.example.com).
Мы используем setcookie($name, $value, $expires) php setcookie($name, $value, $expires) наивно (не указывается явный путь или домен), чтобы установить cookie, а затем очистить файлы cookie (когда пользователь выходит из системы), назначив пустую строку значению. Это всегда срабатывало нормально, и каждый уникальный субдомен использовал свои собственные файлы cookie.
IE10 теперь «разделяет» cookie, который был установлен в TLD со всеми подобластями. Первоначальный симптом, который мы наблюдали, заключался в том, что никто не мог выйти из поддомена. Мы заметили несколько вещей:
Кто-нибудь еще наблюдал подобное поведение по тому, как IE10 хранит / применяет файлы cookie относительно поддоменов? Существует ли какое-либо обходное решение, отличное от того, в каком домене применяется cookie при отправке исходного заголовка Set-Cookie?
Я только что столкнулся с этой проблемой.
Вот ссылка на кого-то, изучающего эту ошибку / проблему: Cookies с и без указанного домена (несовместимость браузера)
Это также может быть связано с: Cookie для субдомена, но IE Developer Tools показывает cookie в корневом домене. Что мне не хватает?
Мое заключение заключается в том, что при настройке файла cookie из корневого домена, отличного от www ( http://sites.com ), в IE это рассматривается как групповой файл cookie для всех поддоменов. Chrome и Firefox не показывают этого поведения – они связывают набор файлов cookie из корневого домена, отличного от www, как связанного только с этим корнем.
Я закодировал примеры сайтов с использованием .net webforms, IIS и моего файла hosts. У меня было 3 сайта: a.site.com, b.site.com и site.com. Все они служили куки с тем же именем. Назовем это «ShoppingCart».
Вы можете установить несколько свойств в файлах cookie, включая домен, к которому должен быть связан файл cookie. Я оставил это свойство неопределенным / undefined .net. Когда Chrome получил файл cookie с каждого сайта, он отобразил домен куки-файла как явно из домена, указанного в адресной строке браузера. В IE это было не так. IE рассматривает cookie с сайта http://sites.com как определяемый как «.sites.com», и согласно RFC для файлов cookie это означает, что он доступен из всех поддоменов.
Также в IE, если несколько файлов cookie установлены с тем же именем, IE возвращает их на сервер в том порядке, в котором они были установлены. Поэтому, если я сначала захожу на сайт http://sites.com, а затем на http://a.sites.com, а затем обновляюсь, IE просматривает cookie с сайта http://sites.com как действительный файл cookie для отправки на сервер в это запрос для http://a.sites.com, который отправляется вместе с файлом cookie для http://a.sites.com , за исключением того, что cookie для http://sites.com является первым в списке.
В .net, из того, что я видел, файлы cookie обычно доступны по имени, а не по индексу. Поэтому, когда код на стороне сервера пытается получить доступ к значению для ключа с именем «ShoppingCart», он будет захватывать значение для первого сайта, который устанавливает значение cookie – здесь это будет http://sites.com .
В целом – не используйте не-www-домены, когда у вас есть поддомены, которые имеют общие имена файлов cookie, потому что, в то время как Chrome / Firefox обрабатывает ассоциацию домена, как и следовало ожидать, IE вызывает ошибочное поведение.
Редактировать–
Чтобы уточнить, кто читает это, я использовал IE10 для изучения этой проблемы.
Супер простой способ исправить это, если у вас несколько доменов PHP в домене.
Например, если у вас есть WordPress на корневой основе (example.com), и у вас есть настраиваемое приложение PHP на субдомене (a.example.com), то либо в вашем приложении, либо в WordPress вам нужно установить другое SessionName.
Добавьте session_name () до вашего session_start (), который должен дать два отдельных имени сеансу и, следовательно, не столкнуться.
session_name('AppSession'); session_start();
Легко.
Да, это известные проблемы, кажется, читайте здесь: http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx
Они ссылаются на этот тест: http://debugtheweb.com/test/cookieinherit.aspx и http://www.debugtheweb.com/test/cookieinherit.aspx
У меня такая же проблема в IE 11.0.9600 для файла cookie php session: Internet Explorer отправляет файлы cookie корневого домена на все его поддомены. Чтобы решить эту проблему, я сохраняю имя домена в переменной сеанса:
$_SESSION['URL'] = str_replace('www.', '', $_SERVER['HTTP_HOST']);
Затем для каждого запроса я проверяю переменную сеанса:
if ( str_replace('www.', '', $_SERVER['HTTP_HOST']) != $_SESSION['URL']) { session_regenerate_id(true); $_SESSION = array(); $_SESSION['URL'] = str_replace('www.', '', $_SERVER['HTTP_HOST']); }
Затем, когда мы переходим из корневого домена в поддомен, мы не будем «в» в том же сеансе.