У меня есть странная причуда с cookie в IE. Когда пользователь входит в сайт, я генерирую новый идентификатор сессии и следовательно должен перезаписать cookie. Поток в основном:
https://secure.example.com/users/login
страница, автоматически получая идентификатор сессииКлиент получает следующие заголовки cookie набора вместе с 302 перенаправлениями к https://secure.example.com/users/mypage
:
CAKEPHP=deleted; expires=Sun, 05 апреля 2009 4:50:35 GMT; путь =/
CAKEPHP=98hnIO23...; expires=Mon, 12 апреля 2010 4:50:36 GMT; соедините каналом =/; безопасный
Клиент, как предполагается, посещает https://secure.example.com/users/mypage
, представление нового идентификатора сессии.
Это работает во всех браузерах, кроме IE (протестированный в 7 и 8). IE сохраняет старый, неаутентифицируемый идентификатор сессии и перенаправляется назад к странице входа в систему. Это работает над моей локальной тестовой средой (использующий самоподписанный сертификат в https://localhost:8443/...
), но не на живом сервере.
Я использую CakePHP и просто проблему a $this->Session->renew()
, который производит вышеупомянутые заголовки cookie.
Какие-либо идеи, как заставить IE принимать новые куки?
Вот полный заголовок:
HTTP/1.0 302 Moved Temporarily
Date: Thu, 08 Apr 2010 02:54:30 GMT
Server: Apache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Set-Cookie: CAKEPHP=deleted; expires=Wed, 08-Apr-2009 02:54:30 GMT; path=/
Set-Cookie: CAKEPHP=d55c...; expires=Thu, 15 Apr 2010 02:54:31 GMT; path=/; secure
Last-Modified: Thu, 08 Apr 2010 02:54:30 GMT
Location: https://secure.example.com/users/mypage
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html; charset=utf-8
Я думаю, что нашел проблему: IE отправляет два cookie идентичного имени. Вот следующий запрос к серверу:
GET /users/mypage HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-silverlight, */ *
Referer: https://secure.example.com/users/login
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322)
Accept-Encoding: gzip, deflate
Host: secure.example.com
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: CAKEPHP=19c6...; CAKEPHP=d55c...
Заметьте, что это отправляет два cookie, тот, который это получило после входа в систему, но также и старого. Это получило старый на уровне основной страницы example.com
, набор с path=/
. Это также отправляет его за запросами к secure.example.com
. Это не становится замененным вышеупомянутым заголовком, вместо этого это добавляет его как дополнительный cookie. Как я могу мешать ему делать это?
Убедитесь, что файлы cookie отправляются для вашего базового домена.
Вероятно, это проблема, так как это поведение, безусловно, различается в разных браузерах.
Я не делал этого в cakephp, но это должно работать
Распространенная проблема заключается в том, что при второй попытке установить cookie отсутствует надлежащий заголовок P3P, и, таким образом, попытка прикоснуться к cookie игнорируется.
Было бы полезно, если бы вы разместили заголовки всего потока (например, используйте Fiddler для захвата и просмотра)
У вас могут быть две проблемы. Во-первых, дайте ссылку в @ freddy-rios, разместившем снимок. Если этого не произойдет, то вы можете столкнуться с «ошибкой cookie перенаправления» IE.
IE не всегда учитывает модификацию cookie во время перенаправления. Если вы назначаете идентификатор сеанса в форме входа и не меняете его, тогда перенаправление должно работать нормально. Если вы изменяете файл cookie при перенаправлении, то вы, вероятно, закончите со старым сеансом ... браузер просто отправит старый файл cookie на новый URL-адрес (возможно, то, что он должен делать ... перенаправить исходный запрос ).
Есть несколько способов справиться с этим. Самым уродливым на сегодняшний день является использование перенаправления тегов Javascript или META. Пока вы передаете эти файлы cookie не 300, браузер почти всегда их принимает.
Если вы используете $ this-> Session-> Renew ()
, простое его удаление может решить все ваши проблемы ... особенно если он вызывает session_regenerate_id ()
под капот.
Я бы посоветовал удалить перенаправление и посмотреть, осталась ли проблема. Если это так, то вы можете проигнорировать все, что я сказал. :)