IE10 domyślnie udostępnia pliki cookie w subdomenach

Question

Wygląda na to, że IE10 radzi sobie z plikami cookie i subdomenami inaczej niż inne główne przeglądarki (IE8, IE9, Firefox, Chrome, Safari).

Używamy subdomen obszernie w środowiskach testowych, np:

• user1.devel.example.com
• user2.devel.example.com
• qa.example.com

Nasze środowisko produkcyjne żyje na szczycie, np example.com (i technicznie również na stronie www.example.com).

Naiwnie używamy funkcji php setcookie($name, $value, $expires) (nie określono jawnej ścieżki ani domeny), aby ustawić plik cookie, a następnie wyczyścić pliki cookie (gdy użytkownik się wylogowuje), przypisując pusty ciąg do wartości. To zawsze działało dobrze, a każda unikalna subdomena używała własnych plików cookie.

IE10 teraz "dzieli" plik cookie, który został ustawiony w TLD ze wszystkimi subdomenami. Pierwszym objawem, który zaobserwowaliśmy, było to, że nikt nie mógł się wylogować z poddomeny. Zaobserwowaliśmy kilka rzeczy:

• Mimo że dzieli się wartością, żadna poddomena nie jest w stanie usunąć pliku cookie.
• Gdy TLD usuwa plik cookie, jest natychmiast usuwany ze wszystkich poddomen.

Czy ktoś inny zaobserwował podobne zachowanie do sposobu przechowywania/stosowania plików cookie w odniesieniu do poddomen? Czy istnieje jakieś obejście, poza wyraźnym określeniem, do której domeny dotyczy plik cookie podczas wysyłania początkowego nagłówka Set-Cookie?

Answer 1

Właśnie spotkałem się z tym problemem.

Tu jest link do kogoś odkrywania tego błędu/problemu: Cookies with and without the Domain Specified (browser inconsistency)

Może to być również powiązane: Cookie set for subdomain, but IE Developer Tools show cookie at root domain. What am I missing?

Mój wniosek jest taki, że przy ustalaniu cookie z domeny głównej non-www (http://sites.com), w IE jest to traktowane jako plik wieloznaczny dla wszystkich subdomen. Chrome i Firefox nie wykazują takiego zachowania - kojarzą zestaw plików cookie z domeny głównej innej niż www, ponieważ są powiązane tylko z tym katalogiem głównym.

Zakodowałem przykładowe witryny za pomocą formularzy webowych .net, IIS i mojego pliku hosts. Miałem 3 witryny: a.site.com, b.site.com i site.com. Wszystkie serwowały ciasteczka o dokładnie takiej samej nazwie. Nazwijmy to "ShoppingCart".

Można ustawić wiele właściwości plików cookie, w tym domenę, z którą plik cookie powinien być powiązany. Zostawiłem tę właściwość do zdefiniowania/pozostawienia niezdefiniowaną przez .net. Gdy Chrome otrzymał plik cookie z każdej witryny, wyświetlił domenę pliku cookie jako jawnie z domeny wymienionej na pasku adresu przeglądarki. W IE tak nie było. IE traktuje plik cookie z http://sites.com jako zdefiniowany jako ".sites.com", a zgodnie z RFC dla plików cookie oznacza to, że jest dostępny dla wszystkich poddomen.

Również w IE, jeśli wiele plików cookie jest ustawionych pod tą samą nazwą, IE zwraca je do serwera w kolejności, w jakiej zostały ustawione. Więc jeśli najpierw odwiedzę http://sites.com, a następnie odwiedzę http://a.sites.com, a następnie odświeżę, IE wyświetli plik cookie z http://sites.com jako prawidłowy plik cookie, który zostanie wysłany na serwer w jego żądaniu na http://a.sites.com, który jest wysyłany wraz z plikiem cookie dla http://a.sites.com, z wyjątkiem pliku cookie dla http://sites.com pierwszy na liście.

W .net, z tego, co widziałem, pliki cookie są zazwyczaj dostępne przez nazwę klucza, a nie przez indeks. Tak więc, gdy kod po stronie serwera próbuje uzyskać dostęp do wartości klucza o nazwie "ShoppingCart", pobierze wartość dla pierwszej witryny, która ustawi wartość cookie - tutaj będzie to http://sites.com.

Podsumowując - nie używaj domen innych niż www, gdy masz subdomeny, które mają wspólne nazwy tych samych plików cookie, ponieważ podczas gdy przeglądarka Chrome/Firefox obsługuje powiązanie domeny, jak się spodziewasz, IE powoduje błędne zachowanie.

Edit--

Właśnie w celu wyjaśnienia, aby ktokolwiek czytając to, używałem IE10 do zbadania tego problemu.

Answer 2

Mam taki sam problem w IE 11.0.9600 dla pliku cookie sesji php: Internet Explorer wysyła pliki cookie domeny głównej do wszystkich swoich poddomen. Aby rozwiązać ten problem, przechowywać nazwę domeny w zmiennej sesji:

$_SESSION['URL'] = str_replace('www.', '', $_SERVER['HTTP_HOST']); 

Następnie dla każdego żądania, sprawdzić zmiennej sesji:

if (str_replace('www.', '', $_SERVER['HTTP_HOST']) != $_SESSION['URL']) { 
    session_regenerate_id(true); 
    $_SESSION = array(); 
    $_SESSION['URL'] = str_replace('www.', '', $_SERVER['HTTP_HOST']); 
} 

Wtedy, kiedy poruszamy się od domeny głównej do poddomena, nie będziemy "wchodzić" w tę samą sesję.

Answer 3

Tak, jest to znane problemy Wydaje przeczytać tutaj: http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx

Odnoszą się one do tego testu: http://debugtheweb.com/test/cookieinherit.aspx i http://www.debugtheweb.com/test/cookieinherit.aspx

Answer 4

Super łatwy sposób aby to naprawić, jeśli masz wiele witryn PHP na domenie .

Na przykład - jeśli masz Wordpress w katalogu głównym (example.com) i masz niestandardową aplikację PHP na poddomenie (a.example.com), to w aplikacji lub Wordpress musisz ustawić inną nazwę sesji .

Dodaj session_name() przed session_start(), które powinno dać dwie oddzielne nazwy sesji, a zatem nie kolidować.

session_name('AppSession'); 
session_start(); 

Łatwy.