subdomain.example.com สามารถตั้งค่าคุกกี้ที่สามารถอ่านได้โดย example.com หรือไม่

ฉันไม่อยากจะเชื่อเลยว่ามันยากที่จะตัดสิน

แม้จะอ่าน RFC แล้วก็ยังไม่ชัดเจนสำหรับฉันหากเซิร์ฟเวอร์ที่ subdomain.example.com สามารถตั้งค่าคุกกี้ที่สามารถอ่านได้โดย example.com

subdomain.example.com สามารถตั้งค่าคุกกี้ที่มีแอตทริบิวต์ของโดเมนคือ. example.com RFC 2965 ดูเหมือนจะระบุอย่างชัดเจนว่าคุกกี้ดังกล่าวจะไม่ถูกส่งไปที่ example.com แต่อย่างเท่าเทียมกันบอกว่าหากคุณตั้งค่า Domain = example.com จุดจะได้รับการเตรียมการเช่นเดียวกับที่คุณพูดว่า. example.com เมื่อนำมารวมกันสิ่งนี้ดูเหมือนจะบอกว่าถ้า example.com ส่งคืนชุดคุกกี้ที่มี Domain = example.com ก็จะไม่ได้รับคุกกี้นั้นกลับมา! มันไม่ถูกต้อง

ทุกคนสามารถอธิบายได้ว่ากฎจริงๆคืออะไร

การอ้างอิงจากRFC2109เดียวกันกับที่คุณอ่าน:

       * Set-Cookie จาก request-host x.foo.com สำหรับ Domain = .foo.com
         ได้รับการยอมรับ

ดังนั้นสามารถตั้งค่าคุกกี้สำหรับsubdomain.example.com .example.comจนถึงตอนนี้ดีมาก

       กฎต่อไปนี้นำไปใช้กับการเลือกค่าคุกกี้ที่เกี่ยวข้อง
       ในบรรดาคุกกี้ทั้งหมดที่เอเจนต์ผู้ใช้มี

       การเลือกโดเมน
            ชื่อโฮสต์แบบเต็มของเซิร์ฟเวอร์ต้นทางจะต้องตรงกับโดเมน
            แอตทริบิวต์ Domain ของคุกกี้

ดังนั้นเรามีการจับคู่โดเมนหรือไม่

   * A เป็นสตริง FQDN และมีรูปแบบ NB โดยที่ N เป็นชื่อที่ไม่ว่างเปล่า
     string, B มีรูปแบบ. B 'และ B' เป็นสตริง FQDN (ดังนั้น xycom
     จับคู่โดเมน. y.com แต่ไม่ใช่ y.com)

แต่ตอนนี้example.comจะไม่จับคู่โดเมน.example.comตามคำจำกัดความ แต่www.example.com(หรือ "ชื่อที่ไม่ว่าง" อื่น ๆ ในโดเมน) จะเป็นเช่นนั้น ในทางทฤษฎี RFC นี้ล้าสมัยโดยRFC2965ซึ่งกำหนดสิ่งต่าง ๆ เกี่ยวกับการบังคับใช้จุดนำสำหรับโดเมนในSet-Cookie2การดำเนินงาน

ที่สำคัญกว่านั้นตามที่ @Tony เป็นโลกแห่งความจริง หากต้องการดูสิ่งที่ตัวแทนผู้ใช้จริงกำลังทำอยู่ให้ดู

nsCookieService.cpp ของ Firefox 3

และ

cookie_monster.cc ของ Chrome

สำหรับมุมมองในสิ่งที่เกิดขึ้นจริงเว็บไซต์กำลังทำลองเล่นกับwgetใช้--save-cookies, --load-cookiesและ--debugที่จะเห็นสิ่งที่เกิดขึ้น

คุณจะพบว่าในความเป็นจริงไซต์ส่วนใหญ่ใช้ชุดค่าผสมSet-CookieRFC รุ่นเก่ากับค่า "โฮสต์" โดยปริยายโดยไม่มีจุดนำ (ตามtwitter.com ) หรือการตั้งค่าโดเมน (ด้วยจุดนำ) และการเปลี่ยนเส้นทาง ไปยังเซิร์ฟเวอร์เช่นwww.example.com(เช่นgoogle.comทำ)

หากเบราว์เซอร์ใช้RFC 6265ซึ่งเบราว์เซอร์ที่ทันสมัยควรทำในจุดนี้คุกกี้ที่ตั้งค่าไว้.example.comจะมีจุดนำหน้า (ส่วน 5.2.3) และจากนั้นคุกกี้จะถูกส่งไปยังโดเมนที่ไม่มีการปิดบังและทั้งหมด โดเมนย่อย

อย่าพึ่งพาพฤติกรรมนี้หากคุณมีปริมาณการใช้ข้อมูลสูงจากเบราว์เซอร์รุ่นเก่า RFC นี้เฉพาะวันที่ถึง 2011

มันไม่ควรจะเป็นไปได้ อย่างไรก็ตามอย่างที่คุณพูดเนื่องจากนี่ไม่ใช่มาตรฐานที่มีการบันทึกอย่างกว้างขวางจึงขึ้นอยู่กับซอฟต์แวร์ที่คุณใช้

เบราว์เซอร์ที่ทันสมัยส่วนใหญ่เป็นไปตาม "รูปแบบการรักษาความปลอดภัยเว็บ" ที่กำหนดไว้ รูปแบบการควบคุมพฤติกรรมของเบราว์เซอร์เกี่ยวกับความปลอดภัยอย่างมีประสิทธิภาพในสิ่งต่าง ๆ เช่นคุกกี้ (โดยเฉพาะวิธีที่พวกเขาจะถูกส่งกลับไปยังเว็บไซต์ที่กำหนด) โมเดลมีกฎว่า "เบราว์เซอร์ไม่ส่งคุกกี้ไปยังชื่อโดเมนที่ไม่ได้ตั้งค่า"

ดังที่กล่าวไว้ domain.com ควรจะสามารถตั้งค่าคุกกี้สำหรับ js.domain.com อย่างไรก็ตาม js.domain.com สามารถตั้งค่าคุกกี้ได้เองเท่านั้น แต่ทั้งหมดนี้ขึ้นอยู่กับเบราว์เซอร์ที่คุณใช้