การเข้าถึงคุกกี้ HTTP แบบไม่พร้อมกัน

Victor Costan
X GitHub

Cookie Store API คืออะไร

Cookie Store API จะแสดงคุกกี้ HTTP แก่ Service Worker และ เสนอทางเลือกแบบไม่พร้อมกันสำหรับ document.cookie API ช่วยให้ ดำเนินการต่อไปนี้ได้ง่ายขึ้น

  • หลีกเลี่ยงข้อขัดข้องในเทรดหลักด้วยการเข้าถึงคุกกี้แบบไม่พร้อมกัน
  • หลีกเลี่ยงการหยั่งสัญญาณสำหรับคุกกี้ เนื่องจากการเปลี่ยนแปลงต่างๆ กับคุกกี้อาจสังเกตได้
  • เข้าถึงคุกกี้จาก Service Worker

อ่านอธิบาย

สถานะปัจจุบัน

ขั้นตอน สถานะ
1. สร้างคำอธิบาย เสร็จสมบูรณ์
2. สร้างข้อกำหนดคร่าวๆ เบื้องต้น เสร็จสมบูรณ์
**3. รวบรวมความคิดเห็นและ ทำซ้ำตามข้อกำหนด** **กำลังดำเนินการ**
4. ช่วงทดลองใช้จากต้นทาง หยุดชั่วคราว
5. เปิดตัว ยังไม่เริ่ม

ฉันจะใช้การจัดเก็บคุกกี้แบบไม่พร้อมกันได้อย่างไร

เปิดใช้ช่วงทดลองใช้จากต้นทาง

หากต้องการลองใช้ในเครื่อง คุณเปิดใช้ API ในบรรทัดคำสั่งได้

chrome --enable-blink-features=CookieStore

การส่งผ่านแฟล็กนี้ในบรรทัดคำสั่งจะเปิดใช้ API ได้ทั่วโลกใน Chrome สำหรับ เซสชันปัจจุบัน

หรือคุณจะเปิดใช้ #enable-experimental-web-platform-features ก็ได้ ธงในchrome://flags

คุณ (อาจจะ) ไม่ต้องการคุกกี้

ก่อนที่จะเจาะลึกเรื่อง API ใหม่ เราอยากทราบว่าคุกกี้ยังคงเป็นเว็บ พื้นที่เก็บข้อมูลดั้งเดิมที่แย่ที่สุดในฝั่งไคลเอ็นต์ของแพลตฟอร์ม และควรใช้เป็น ทางเลือกสุดท้าย นี่ไม่ใช่เรื่องบังเอิญ คุกกี้เป็นฝั่งไคลเอ็นต์แรกของเว็บ พื้นที่เก็บข้อมูล และเราได้เรียนรู้สิ่งต่างๆ มากมายนับตั้งแต่นั้น

เหตุผลหลักในการหลีกเลี่ยงคุกกี้ ได้แก่

  • คุกกี้จะนำสคีมาพื้นที่เก็บข้อมูลไปไว้ในแบ็กเอนด์ API คำขอ HTTP แต่ละรายการจะมีสแนปชอตของโถคุกกี้ วิธีนี้ช่วยให้คุณ วิศวกรระบบแบ็กเอนด์ที่จะแนะนำทรัพยากร Dependency ในรูปแบบคุกกี้ปัจจุบัน ครั้งเดียว ในกรณีนี้ ส่วนหน้าของจะเปลี่ยนสคีมาพื้นที่เก็บข้อมูลไม่ได้หากไม่ทำให้ใช้งานได้ การเปลี่ยนแปลงที่ตรงกันกับแบ็กเอนด์

  • คุกกี้มีรูปแบบการรักษาความปลอดภัยที่ซับซ้อน ฟีเจอร์ของแพลตฟอร์มเว็บสมัยใหม่เป็นไปตามนโยบายต้นทางเดียวกัน ซึ่งหมายความว่า แต่ละแอปพลิเคชันจะมีแซนด์บ็อกซ์ของตัวเอง และเป็นอิสระจาก แอปพลิเคชันอื่นๆ ที่ผู้ใช้อาจใช้งานอยู่ ขอบเขตของคุกกี้ ทำให้เรื่องราวด้านความปลอดภัยซับซ้อนขึ้นมาก สรุปที่จะเพิ่มขนาดของบทความนี้เป็น 2 เท่า

  • คุกกี้มีค่าใช้จ่ายประสิทธิภาพสูง เบราว์เซอร์ต้องรวมภาพรวมของ คุกกี้ของคุณในคำขอ HTTP ทุกรายการ ดังนั้น การเปลี่ยนแปลงกับคุกกี้ทุกครั้ง กระจายไปยังพื้นที่เก็บข้อมูลและสแต็กเครือข่ายต่างๆ เบราว์เซอร์สมัยใหม่มี การใช้การจัดเก็บคุกกี้ที่เพิ่มประสิทธิภาพ แต่เราไม่สามารถทำได้ คุกกี้มีประสิทธิภาพเทียบเท่ากับกลไกการจัดเก็บข้อมูลอื่นๆ ลงในสแต็กเครือข่าย

ด้วยเหตุผลข้างต้นทั้งหมด เว็บแอปพลิเคชันสมัยใหม่จึงควรหลีกเลี่ยงคุกกี้และ แต่จะจัดเก็บตัวระบุเซสชันไว้ใน IndexedDB และ เพิ่มตัวระบุลงในส่วนหัวหรือเนื้อหาในคำขอ HTTP ที่เจาะจง ผ่าน API การดึงข้อมูล

อย่างไรก็ตาม คุณยังคงอ่านบทความนี้ เนื่องจากคุณมี เหตุผลที่ควรใช้คุกกี้...

ผู้น่าเคารพ document.cookie API เป็นแหล่งที่มาของการกระเพื่อมที่เหมาะสมสำหรับแอปพลิเคชันของคุณ ตัวอย่างเช่น เมื่อใดก็ตามที่คุณใช้ Getter document.cookie เบราว์เซอร์จะต้องหยุดดำเนินการ JavaScript จนกว่าจะมีข้อมูลคุกกี้ที่คุณขอ การดำเนินการนี้อาจใช้เวลา ประมวลผล Hop หรือดิสก์อ่าน และจะทำให้ UI ของคุณกระตุก

การแก้ไขปัญหาที่ตรงไปตรงมาคือการเปลี่ยนจาก document.cookie Getter ไปยัง Cookie Store API แบบอะซิงโครนัส

await cookieStore.get('session_id');

// {
//   domain: "example.com",
//   expires: 1593745721000,
//   name: "session_id",
//   path: "/",
//   sameSite: "unrestricted",
//   secure: true,
//   value: "yxlgco2xtqb.ly25tv3tkb8"
// }

สามารถแทนที่ตัวตั้งค่า document.cookie ได้ในลักษณะเดียวกัน โปรดทราบ ว่ามีการรับประกันว่าการเปลี่ยนแปลงดังกล่าวจะถูกนำไปใช้หลังจาก Promise ส่งคืนโดย cookieStore.set แก้ปัญหา

await cookieStore.set({name: 'opt_out', value: '1'});

// undefined

สังเกตการณ์ ไม่สำรวจ

แอปพลิเคชันที่ได้รับความนิยมสำหรับการเข้าถึงคุกกี้จาก JavaScript ตรวจพบเมื่อ ผู้ใช้ออกจากระบบและอัปเดต UI ซึ่งขณะนี้ทำได้โดยแบบสำรวจ document.cookie ทำให้เกิดการกระตุกและส่งผลเสียต่อแบตเตอรี่ ชีวิต

Cookie Store API เป็นอีกทางเลือกหนึ่งในการสังเกตการณ์คุกกี้ การเปลี่ยนแปลง ซึ่งไม่จำเป็นต้องมีแบบสำรวจ

cookieStore.addEventListener('change', event => {
  for (const cookie of event.changed) {
    if (cookie.name === 'session_id') sessionCookieChanged(cookie.value);
  }
  for (const cookie of event.deleted) {
    if (cookie.name === 'session_id') sessionCookieChanged(null);
  }
});

ยินดีต้อนรับ Service Worker

ระบบยังไม่ได้สร้าง document.cookie API เนื่องจากการออกแบบให้ซิงโครนัส พร้อมใช้งานสำหรับ Service Worker Cookie Store API ทำงานไม่พร้อมกัน ดังนั้นจึงได้รับอนุญาตให้ให้บริการ ผู้ปฏิบัติงาน

การโต้ตอบกับคุกกี้จะทำงานในลักษณะเดียวกันในบริบทของเอกสารและใน Service Worker

// Works in documents and service workers.
async function logOut() {
  await cookieStore.delete('session_id');
}

อย่างไรก็ตาม การสังเกตการเปลี่ยนแปลงของคุกกี้จะแตกต่างออกไปเล็กน้อยใน Service Worker การปลุก โปรแกรมทำงานของบริการอาจมีค่าใช้จ่ายสูง เราจึงต้องอธิบาย การเปลี่ยนแปลงคุกกี้ที่พนักงานสนใจ

ในตัวอย่างด้านล่าง แอปพลิเคชันที่ใช้ IndexedDB เพื่อแคชข้อมูลผู้ใช้ ตรวจสอบการเปลี่ยนแปลงของคุกกี้เซสชัน และทิ้งข้อมูลที่แคชไว้เมื่อ ผู้ใช้ออกจากระบบ

// Specify the cookie changes we're interested in during the install event.
self.addEventListener('install', event => {
  event.waitUntil(cookieStore.subscribeToChanges([{name: 'session_id'}]));
});

// Delete cached data when the user logs out.
self.addEventListener('cookiechange', event => {
  for (const cookie of event.deleted) {
    if (cookie.name === 'session_id') {
      indexedDB.deleteDatabase('user_cache');
      break;
    }
  }
});

แนวทางปฏิบัติแนะนำ

เร็วๆ นี้

ความคิดเห็น

หากลองใช้ API นี้ โปรดแจ้งให้เราทราบว่าคุณคิดอย่างไร โปรดส่งโดยตรง ความคิดเห็นเกี่ยวกับรูปร่าง API ไปยัง ข้อมูลจำเพาะ และรายงานข้อบกพร่องการใช้งานไปยัง Blink>Storage>CookiesAPI คอมโพเนนต์กะพริบ

เราสนใจที่จะเรียนรู้เกี่ยวกับการวัดประสิทธิภาพและการใช้ นอกเหนือจากกรณีที่ระบุไว้ในคำอธิบาย

แหล่งข้อมูลเพิ่มเติม