Bagaimana cara kerja domain cookie browser?

Karena masalah cookie domain / subdomain aneh yang saya dapatkan, saya ingin tahu bagaimana browser menangani cookie. Jika mereka melakukannya dengan cara yang berbeda, akan menyenangkan mengetahui perbedaannya.

Dengan kata lain - ketika browser menerima cookie, cookie itu MUNGKIN memiliki domain dan jalur yang dilampirkan padanya. Atau tidak, dalam hal ini browser mungkin menggantikan beberapa default untuk mereka. Pertanyaan 1: apa itu?

Kemudian, ketika browser akan membuat permintaan, ia memeriksa cookie dan menyaring yang harus dikirim untuk permintaan itu. Ia melakukannya dengan mencocokkannya dengan jalur dan domain permintaan. Pertanyaan 2: apa aturan yang cocok?

Alasan saya menanyakan hal ini adalah karena saya tertarik pada beberapa kasus tepi. Suka:

• Akankah cookie untuk .example.comtersedia www.example.com?
• Akankah cookie untuk .example.comtersedia example.com?
• Akankah cookie untuk example.comtersedia www.example.com?
• Akankah cookie untuk example.comtersedia anotherexample.com?
• Akan www.example.comdapat mengatur cookie untuk example.com?
• Akan www.example.comdapat mengatur cookie untuk www2.example.com?
• Akan www.example.comdapat mengatur cookie untuk .com?
• Dll

Menambahkan 2:

Juga, bisakah seseorang menyarankan bagaimana saya harus mengatur cookie sehingga:

• Itu dapat diatur dengan salah satu www.example.comatau example.com;
• Ini dapat diakses oleh keduanya www.example.comdan example.com.

Meskipun ada RFC 2965 ( Set-Cookie2, sudah RFC 2109 usang ) yang harus mendefinisikan cookie saat ini, sebagian besar browser tidak sepenuhnya mendukung itu tetapi hanya mematuhi spesifikasi asli oleh Netscape .

Ada perbedaan antara nilai atribut Domain dan domain efektif: yang pertama diambil dari Set-Cookiebidang header dan yang terakhir adalah interpretasi dari nilai atribut itu. Menurut RFC 2965, yang berikut ini harus berlaku:

• Jika bidang header Set-Cookie tidak memiliki atribut Domain , domain efektif adalah domain dari permintaan.
• Jika ada atribut Domain hadir, nilainya akan digunakan sebagai domain efektif (jika nilainya tidak dimulai dengan .itu akan ditambahkan oleh klien).

Memiliki domain yang efektif juga harus sesuai dengan domain yang diminta saat ini untuk ditetapkan; kalau tidak cookie akan direvisi. Aturan yang sama berlaku untuk memilih cookie yang akan dikirim dalam permintaan.

Memetakan pengetahuan ini ke pertanyaan Anda, hal-hal berikut ini harus berlaku:

• Cookie dengan Domain=.example.com akan tersedia untuk www.example.com
• Cookie dengan Domain=.example.com akan tersedia untuk example.com
• Cookie dengan Domain=example.comakan dikonversi ke .example.comdan dengan demikian akan juga tersedia untuk www.example.com
• Cookie dengan Domain=example.comakan tidak tersedia untuk anotherexample.com
• www.example.com akan dapat mengatur cookie untuk example.com
• www.example.com akan tidak dapat set cookie untuk www2.example.com
• www.example.com akan tidak dapat set cookie untuk .com

Dan untuk mengatur dan membaca cookie untuk / oleh www.example.com dan example.com , atur untuk .www.example.comdan .example.commasing - masing. Tetapi yang pertama ( .www.example.com) hanya akan dapat diakses untuk domain lain di bawah domain itu (misalnya untuk www.example.com atau bar.www.example.com ) di mana .example.comjuga dapat diakses oleh domain lain di bawah example.com (mis . Foo. example.com atau bar.example.com ).

Jawaban sebelumnya sedikit ketinggalan jaman.

RFC 6265 diterbitkan pada tahun 2011, berdasarkan pada konsensus browser pada saat itu. Sejak itu, ada beberapa komplikasi dengan domain akhiran publik. Saya sudah menulis artikel yang menjelaskan situasi saat ini - http://bayou.io/draft/cookie.domain.html

Untuk meringkas, aturan yang harus diikuti tentang domain cookie:

• The domain asal dari cookie adalah domain dari permintaan berasal.

• Jika domain asal adalah IP, atribut domain cookie tidak boleh ditetapkan.

• Jika atribut domain cookie tidak disetel, cookie hanya berlaku untuk domain asalnya.

• Jika atribut domain cookie ditetapkan,

  • cookie ini berlaku untuk domain itu dan semua subdomainnya;
  • domain cookie harus sama dengan, atau orang tua dari, domain asal
  • domain cookie tidak boleh TLD, sufiks publik, atau orangtua dari sufiks publik.

Dapat diturunkan bahwa cookie selalu berlaku untuk domain asalnya.

Domain cookie tidak boleh memiliki titik awal, seperti di .foo.com- cukup gunakanfoo.com

Sebagai contoh,

• x.y.z.comdapat mengatur domain cookie untuk dirinya sendiri atau orang tua - x.y.z.com, y.z.com, z.com. Tapi tidak com, yang merupakan sufiks publik.
• cookie dengan domain = y.z.comberlaku untuk y.z.com, x.y.z.com, a.x.y.z.comdll

Contoh akhiran publik - com, edu, uk, co.uk, blogspot.com,compute.amazonaws.com

Untuk cakupan yang luas, tinjau isi RFC2965 . Tentu saja itu tidak berarti bahwa semua browser berperilaku dengan cara yang persis sama.

Namun secara umum aturan untuk Path default jika tidak ada yang ditentukan dalam cookie adalah path di URL dari mana header Set-Cookie tiba. Demikian pula default untuk Domain adalah nama host lengkap di URL dari mana Set-Cookie tiba.

Aturan yang cocok untuk domain mengharuskan Domain cookie untuk mencocokkan host yang menjadi tujuan permintaan tersebut. Cookie dapat menentukan kecocokan domain yang lebih luas dengan menyertakan *. dalam atribut domain Set-Cookie (area yang peramban ini dapat bervariasi). Mencocokkan jalur (dengan asumsi pencocokan domain) adalah masalah sederhana bahwa jalur yang diminta harus berada di dalam jalur yang ditentukan pada cookie. Biasanya cookie sesi diatur dengan path = / atau path = / applicationName / sehingga cookie tersedia untuk semua permintaan ke dalam aplikasi.

• Akankah cookie untuk .example.com tersedia untuk www.example.com? Iya
• Akankah cookie untuk .example.com tersedia untuk example.com? Tidak tahu
• Apakah cookie untuk example.com tersedia untuk www.example.com? Seharusnya tidak ... *
• Akankah cookie untuk example.com tersedia untuk anotherexample.com? Tidak
• Apakah www.example.com dapat mengatur cookie untuk example.com? Iya
• Apakah www.example.com dapat mengatur cookie untuk www2.example.com? Tidak (Kecuali via .example.com)
• Apakah www.example.com dapat mengatur cookie untuk .com? Tidak ( Tidak dapat menyetel cookie setinggi ini di namespace dan Anda tidak dapat mengatur cookie untuk sesuatu seperti .co.uk) .

*Saya tidak dapat menguji ini sekarang tetapi saya memiliki firasat bahwa setidaknya IE7 / 6 akan memperlakukan jalan example.comseolah-olah itu .example.com.

RFC terakhir (ketiga tepatnya) untuk masalah ini adalah RFC-6265 (Obsoletes RFC-2965 yang pada gilirannya usang RFC-2109).

Menurutnya jika server menghilangkan atribut Domain, agen pengguna akan mengembalikan cookie hanya ke server asal (server di mana sumber daya yang diberikan berada). Tetapi itu juga memperingatkan bahwa beberapa agen pengguna yang ada memperlakukan atribut Domain yang tidak ada seolah-olah atribut Domain ada dan berisi nama host saat ini (Misalnya, jika example.com mengembalikan header Set-Cookie tanpa atribut Domain, agen pengguna ini akan juga mengirim cookie ke www.example.com).

Ketika atribut Domain telah ditentukan, itu akan diperlakukan sebagai nama domain lengkap (jika ada titik terdepan dalam atribut itu akan diabaikan). Server harus cocok dengan domain yang ditentukan dalam atribut (memiliki nama domain yang persis sama atau menjadi subdomainnya) untuk mendapatkan cookie ini. Lebih tepatnya ditentukan di sini .

Jadi, misalnya:

• atribut cookie Domain=.example.comsetara denganDomain=example.com
• cookie dengan atribut Domain tersebut akan tersedia untuk example.com dan www.example.com
• cookie dengan atribut Domain tersebut tidak akan tersedia untuk orang lain-example.com
• Menentukan atribut cookie seperti Domain=www.example.comakan menutup jalan untuk www4.example.com

PS: trailing koma pada atribut Domain akan menyebabkan agen pengguna mengabaikan atribut = (

Saya menguji semua kasing di Chrome, Firefox, Safari terbaru pada 2019.

Tanggapan untuk Ditambahkan:

• Akankah cookie untuk .example.com tersedia untuk www.example.com? IYA
• Akankah cookie untuk .example.com tersedia untuk example.com? IYA
• Apakah cookie untuk example.com tersedia untuk www.example.com? TIDAK , Domain tanpa wildcard hanya cocok dengan dirinya sendiri.
• Akankah cookie untuk example.com tersedia untuk anotherexample.com? TIDAK
• Apakah www.example.com dapat mengatur cookie untuk example.com? TIDAK , ini akan dapat mengatur cookie untuk '.example.com', tetapi bukan 'example.com'.
• Apakah www.example.com dapat mengatur cookie untuk www2.example.com? TIDAK . Tetapi dapat mengatur cookie untuk .example.com, yang dapat diakses oleh www2.example.com.
• Apakah www.example.com dapat mengatur cookie untuk .com? TIDAK

RFC diketahui tidak mencerminkan kenyataan.

Lebih baik memeriksa draft-ietf-httpstate-cookie , bekerja dalam proses.

Ada aturan yang menentukan apakah browser akan menerima header respons Set-header (penulisan cookie sisi-server), aturan / interpretasi yang sedikit berbeda untuk cookie yang diatur menggunakan Javascript (Saya belum menguji VBScript).

Lalu ada aturan yang menentukan apakah browser akan mengirim cookie bersama dengan permintaan halaman.

Ada perbedaan antara mesin peramban utama cara penanganan kecocokan domain, dan bagaimana parameter dalam nilai jalur ditafsirkan. Anda dapat menemukan beberapa bukti empiris dalam artikel Bagaimana Peramban Menangani Cookie Berbeda

Saya terkejut membaca bagian 3.3.2 tentang menolak cookie:

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

Yang mengatakan bahwa browser harus menolak cookie dari xyzcom dengan domain .z.com, karena 'xy' mengandung sebuah titik. Jadi, kecuali saya salah menafsirkan RFC dan / atau pertanyaan di atas, mungkin ada pertanyaan yang ditambahkan:

Apakah cookie untuk .example.com tersedia untuk www.yyy.example.com? Tidak.

Akankah cookie ditetapkan oleh server asal www.yyy.example.com, dengan domain .example.com, apakah nilainya dikirim oleh agen pengguna ke xxx.example.com? Tidak.

Akan www.example.comdapat mengatur cookie untuk .com?

Tidak, tetapi example.com.frmungkin dapat mengatur cookie untuk example2.com.fr. Firefox melindungi ini dengan mempertahankan daftar TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Rupanya Internet Explorer tidak mengizinkan domain dua huruf untuk mengatur cookie, yang saya kira menjelaskan mengapa o2.iehanya dialihkan ke o2online.ie. Saya sering bertanya-tanya tentang itu.