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

Victor Costan
Twitter GitHub

Cookie Store API คืออะไร

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

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

อ่านคำอธิบาย

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

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

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

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

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

chrome --enable-blink-features=CookieStore

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

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

คุณ (อาจจะ) ไม่จำเป็นต้องใช้คุกกี้

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

สาเหตุหลักในการหลีกเลี่ยงคุกกี้คือ:

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

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

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

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

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

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

วิธีแก้ไขง่ายๆ สำหรับปัญหานี้คือการเปลี่ยนจาก Getter document.cookie เป็น 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 จึงยังไม่พร้อมให้บริการสำหรับโปรแกรมทำงานของบริการ Cookie Store API เป็นแบบอะซิงโครนัส จึงอนุญาตให้ใช้ในโปรแกรมบริการได้

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

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

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

ในตัวอย่างด้านล่าง แอปพลิเคชันที่ใช้ 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 คอมโพเนนต์ Blink

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

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