Jak działają domeny cookie przeglądarki?

Poprzednie odpowiedzi są trochę nieaktualne.

RFC 6265 został opublikowany w 2011 roku, na podstawie ówczesnego konsensusu przeglądarki. Od tego czasu pojawiły się pewne komplikacje związane z domenami przyrostków publicznych. Napisałem artykuł wyjaśniający obecną sytuację - http://bayou.io/draft/cookie.domain.html

Podsumowując, zasady, których należy przestrzegać w odniesieniu do domeny cookie:

• Domena wyjściowa pliku cookie jest domeną zapytanie ofertowe.

• Jeśli domena źródłowa jest adresem IP, atrybut domeny pliku cookie nie może być ustawiony.

• Jeśli atrybut domeny pliku cookie nie jest ustawiony, plik cookie ma zastosowanie tylko do jego domeny wyjściowej.

• Jeśli plik cookie ma atrybut domeny, to]}
  Plik cookie ma zastosowanie do tej domeny i wszystkich jej subdomen.]} Domena pliku cookie musi być taka sama, jak domena macierzysta.]}
  • the domena cookie nie może być domeną TLD, przyrostkiem publicznym ani rodzicem przyrostka publicznego.

Można wywnioskować, że plik cookie zawsze ma zastosowanie do jego domeny wyjściowej.

Domena cookie nie powinna mieć wiodącej kropki, jak w .foo.com - wystarczy użyć foo.com

Jako przykład,

• x.y.z.com może ustawić domenę cookie dla siebie lub rodziców - x.y.z.com, y.z.com, z.com. Ale nie com, który jest publicznym przyrostkiem.
• plik cookie z domeną = y.z.com jest dotyczy y.z.com, x.y.z.com, a.x.y.z.com itd.

Przykłady sufiksów publicznych - com, edu, uk, co.uk, blogspot.com, compute.amazonaws.com

Aby uzyskać obszerny przegląd zawartości RFC2965 . Oczywiście nie musi to oznaczać, że wszystkie przeglądarki zachowują się dokładnie tak samo.

Ogólnie jednak regułą dla domyślnej ścieżki, jeśli żadna nie została określona w pliku cookie, jest ścieżka w adresie URL, z którego pochodzi nagłówek Set-Cookie. Podobnie domyślną dla domeny jest pełna nazwa hosta w adresie URL, z którego pochodzi plik cookie Set.

Zasady dopasowywania domeny wymagają dopasowania domeny cookie gospodarza, do którego wniosek jest składany. Plik cookie może określić szersze dopasowanie domeny za pomocą include *. w atrybucie domeny Set-Cookie (ten jeden obszar, który przeglądarki mogą się różnić). Dopasowanie ścieżki (zakładając, że domena pasuje) jest prostą sprawą, że żądana ścieżka musi znajdować się wewnątrz ścieżki określonej w pliku cookie. Zazwyczaj pliki cookie sesji są ustawiane za pomocą Path = / lub path= / applicationName/, więc plik cookie jest dostępny dla wszystkich żądań w podanie.

• czy ciasteczko dla .example.com być dostępne dla www.example.com Tak
• czy ciasteczko dla .example.com być dostępne dla example.com Nie wiem
• czy ciasteczko dla example.com być dostępne dla www.example.com nie powinno, ale... *
• czy ciasteczko dla example.com być dostępne dla anotherexample.com? Nie
• Will www.example.com możliwość ustawienia pliku cookie dla example.com Tak
• Will www.example.com możliwość ustawienia pliku cookie dla www2.example.com? Nie (Z Wyjątkiem via .example.com)
• Will www.example.com być w stanie ustawić plik cookie dla. com? Nie (nie można ustawić pliku cookie tak wysoko w przestrzeni nazw, ani nie można ustawić go dla czegoś takiego .co.uk).

* nie jestem w stanie tego teraz przetestować, ale mam przeczucie, że przynajmniej IE7/6 potraktowałby ścieżka example.com jakby była .example.com.

Ostatnim (trzecim dokładnie) RFC dla tego problemu jest RFC-6265 (Obsoletes RFC-2965, który z kolei obsoletes RFC-2109).

Zgodnie z nim {[7] } jeśli serwer pomija atrybut domeny, user agent zwróci plik cookie tylko do serwera origin (serwera, na którym znajduje się dany zasób). Ale jest to również Ostrzeżenie że niektórzy obecni agenci użytkownika traktują nieobecny atrybut domeny tak, jakby atrybut domeny był obecny i zawierał bieżącą nazwę hosta (Na przykład, jeśli example.com zwraca nagłówek Set-Cookie bez atrybutu domeny, agenci użytkownika błędnie wyślą plik cookie do www.example.com również).

Gdy atrybut domeny zostanie określony, będzie on traktowany jako pełna nazwa domeny (jeśli w atrybucie znajduje się kropka, zostanie ona zignorowana). Serwer powinien pasować do domeny podanej w atrybutie (mieć dokładnie tę samą nazwę domeny lub być jej subdomeną), aby uzyskać ten plik cookie. Dokładniej to określone tutaj .

Więc, na przykład:

• atrybut cookie Domain=.example.com jest odpowiednikiem Domain=example.com
• pliki cookie z takimi atrybutami domeny będą Dostępne dla example.com i www.example.com
• pliki cookie z takimi atrybutami domeny będą niedostępne dla another-example.com
• podanie atrybutu cookie jak Domain=www.example.com zamknie drogę dla www4.example.com

PS: końcowy przecinek w atrybucie domeny spowoduje, że agent użytkownika zignoruje atrybut =(

Istnieją reguły, które określają, czy przeglądarka będzie akceptować nagłówek odpowiedzi Set-header (zapisywanie plików cookie po stronie serwera), nieco inne reguły / interpretacje dla zestawu plików cookie przy użyciu Javascript(nie testowałem VBScript).

Następnie istnieją reguły, które określają, czy przeglądarka wyśle plik cookie wraz z żądaniem strony.

Istnieją różnice między głównymi silnikami przeglądarki, w jaki sposób obsługiwane są dopasowania domen i jak interpretowane są parametry w wartościach ścieżek. Kilka empirycznych dowodów można znaleźć w artykule Jak różne przeglądarki inaczej obsługują pliki cookie

RFC nie odzwierciedlają rzeczywistości.

Better check draft-ietf-httpstate-cookie, work in progress.

Byłem zaskoczony przeczytaniem sekcji 3.3.2 o odrzucaniu plików cookie:

Http://tools.ietf.org/html/rfc2965

Mówi, że przeglądarka powinna odrzucić plik cookie z x.y.z.com z domeną .z.com, ponieważ "x. y" zawiera kropkę. Tak więc, chyba że źle interpretuję RFC i / lub pytania powyżej, mogą być pytania dodane:

Czy ciasteczko dla .example.com być dostępne dla www.yyy.example.com Nie.

Czy plik cookie ustawiony przez serwer origin www.yyy.example.com, z domeną .example.com, czy jego wartość jest wysyłana przez agenta użytkownika do xxx.example.com Nie.

Czy www.example.com będzie w stanie ustawić plik cookie dla .com?

Nie, ale example.com.fr może być w stanie ustawić plik cookie dla example2.com.fr. Firefox chroni przed tym, utrzymując listę TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Najwyraźniej Internet Explorer nie pozwala dwuliterowym domenom na ustawianie plików cookie, co zapewne wyjaśnia, dlaczego o2.ie po prostu przekierowuje na o2online.ie. Często się nad tym zastanawiałem.