ช่วงทดลองใช้จากต้นทางสำหรับการรองรับส่วนหัว HTTP ในการเข้าถึงพื้นที่เก็บข้อมูล

Natalia Markoborodova

Chrome กำลังเริ่มช่วงทดลองใช้จากต้นทางเพื่อเพิ่มส่วนหัว HTTP ลงใน Storage Access API (SAA) เวอร์ชัน 130: ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูล Sec-Fetch-Storage-Accessส่วนหัวคำขอและActivate-Storage-Accessส่วนหัวการตอบกลับใหม่มีจุดประสงค์เพื่อรองรับทรัพยากรที่ไม่ใช่ iframe และปรับปรุงประสิทธิภาพและประสบการณ์ของผู้ใช้สำหรับเว็บไซต์ที่อาศัยเนื้อหาที่ฝัง เช่น วิดเจ็ตโซเชียลมีเดีย ปฏิทิน และเครื่องมือแบบอินเทอร์แอกทีฟ

ขั้นตอนการทำงานของ JavaScript (และข้อจำกัด)

ก่อนหน้านี้ SAA กำหนดให้ต้องเรียกใช้ JavaScript API ไปยัง document.requestStorageAccess() ทุกครั้งที่โหลดซ้ำ แม้ว่าผู้ใช้จะให้สิทธิ์แล้วก็ตาม แม้ว่าจะมีประสิทธิภาพ แต่วิธีนี้มีข้อจำกัดดังนี้

• การติดต่อเครือข่ายหลายรอบ: กระบวนการนี้มักจะเกี่ยวข้องกับคำขอเครือข่ายและการโหลดหน้าเว็บหลายครั้งก่อนที่เนื้อหาที่ฝังจะทำงานได้อย่างสมบูรณ์
• การพึ่งพา iframe: การดำเนินการ JavaScript กําหนดให้ต้องใช้ iframe หรือทรัพยากรย่อยภายใน iframe ซึ่งจํากัดความยืดหยุ่นสําหรับนักพัฒนาซอฟต์แวร์

เช่น วิดเจ็ตปฏิทินจาก calendar.example ที่ฝังใน website.example โดยใช้เฉพาะ JavaScript จะมีลักษณะดังนี้

1. โหลดตัวยึดตําแหน่ง: website.example ขอวิดเจ็ต เนื่องจากวิดเจ็ต calendar.example ที่ฝังใน website.example ไม่มีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน ระบบจึงแสดงผลวิดเจ็ตตัวยึดตําแหน่งแทน
2. ขอสิทธิ์: ตัวยึดตําแหน่งจะโหลด จากนั้นเรียก document.requestStorageAccess() เพื่อขอสิทธิ์ storage-access
3. ผู้ใช้เลือกให้สิทธิ์
4. โหลดวิดเจ็ตซ้ำ: วิดเจ็ตจะรีเฟรชโดยที่ครั้งนี้มีสิทธิ์เข้าถึงคุกกี้ และโหลดเนื้อหาที่ปรับตามโปรไฟล์ของผู้ใช้ในที่สุด
5. ทุกครั้งที่ผู้ใช้เข้าชมเว็บไซต์ที่ฝังวิดเจ็ต calendar.example อีกครั้ง ขั้นตอนจะเหมือนกับในขั้นตอนที่ 1, 2 และ 4 ทุกประการ ความแตกต่างเพียงอย่างเดียวคือผู้ใช้ไม่จําเป็นต้องให้สิทธิ์เข้าถึงอีกครั้ง

ขั้นตอนนี้ไม่มีประสิทธิภาพ หากผู้ใช้ให้สิทธิ์เข้าถึงพื้นที่เก็บข้อมูลแล้ว การโหลด iframe ครั้งแรก การเรียกใช้ document.requestStorageAccess() และการโหลดซ้ำใน��ายหลังจะกลายเป็นสิ่งไม่จำเป็นและทำให้เกิดเวลาในการตอบสนอง

ขั้นตอนใหม่ที่มีส่วนหัว HTTP

ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลใหม่ช่วยให้โหลดเนื้อหาที่ฝังอยู่ได้มีประสิทธิภาพมากขึ้น รวมถึงทรัพยากรที่ไม่ใช่ iframe

เมื่อใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูล เบราว์เซอร์จะดึงข้อมูลทรัพยากรโดยอัตโนมัติด้วยการตั้งค่าส่วนหัวคำขอ Sec-Fetch-Storage-Access: inactive หากผู้ใช้ให้สิทธิ์แล้ว นักพัฒนาแอปไม่จำเป็นต้องดำเนินการใดๆ เพื่อตั้งค่าส่วนหัวคำขอ เซิร์ฟเวอร์สามารถตอบกลับด้วยส่วนหัว Activate-Storage-Access: retry; allowed-origin="<origin>" และเบราว์เซอร์จะลองส่งคำขออีกครั้งโดยใช้ข้อมูลเข้าสู่ระบบที่จำเป็น

ส่วนหัวของคำขอ

Sec-Fetch-Storage-Access: <access-status>

เมื่อผู้ใช้เข้าชมหน้าที่ฝังเนื้อหาข้ามเว���บไซต์เบราว์เซอร์จะใส่ส่วนหัว Sec-Fetch-Storage-Access ไว้ในคําขอข้ามเว็บไซต์โดยอัตโนมัติ ซึ่งอาจต้องใช้ข้อมูลเข้าสู่ระบบ (เช่น คุกกี้) ส่วนหัวนี้ระบุสถานะสิทธิ์การเข้าถึงคุกกี้ของชิ้นงาน วิธีตีความค่ามีดังนี้

• none: แทรกไม่มีสิทธิ์ storage-access จึงไม่มีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน
• inactive: รายการที่ฝังมีสิทธิ์ storage-access แต่ไม่ได้เลือกใช้สิทธิ์ดังกล่าว การฝังไม่มีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน
• active: ชิ้นงานมีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน ค่านี้จะรวมอยู่ในคําขอข้ามแหล่งที่มาซึ่งมีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน

ส่วนหัวการตอบกลับ

Activate-Storage-Access: <retry-or-reload>

ส่วนหัว Activate-Storage-Access จะสั่งให้เบราว์เซอร์ลองส่งคำขออีกครั้งด้วยคุกกี้ หรือโหลดทรัพยากรโดยตรงโดยเปิดใช้งาน SAA ส่วนหัวอาจมีค่าดังต่อไปนี้

• load: สั่งให้เบราว์เซอร์ให้���ิทธิ์ผู้ฝังเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันสําหรับทรัพยากรที่ขอ
• retry: เซิร์ฟเวอร์ตอบกลับว่าเบราว์เซอร์ควรเปิดใช้งานสิทธิ์การเข้าถึงพื้นที่เก็บข้อมูล จากนั้นลองส่งคำขออีกครั้ง

Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

การรองรับทรัพยากรที่ไม่ใช่ iframe

การอัปเดตส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลจะเปิดใช้ SAA สำหรับเนื้อหาที่ฝังซึ่งไม่ใช่ iframe เช่น รูปภาพที่โฮสต์ในโดเมนอื่น ก่อนหน้านี้ ไม่มี API แพลตฟอร์มเว็บใดที่อนุญาตให้โหลดทรัพยากรดังกล่าวด้วยข้อมูลเข้าสู่ระบบในเบราว์เซอร์หากไม่มีคุกกี้ของบุคคลที่สาม ตัวอย่างเช่น embedding-site.example สามารถขอรูปภาพได้ดังนี้

   <img src="https://server.example/image"/>

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

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

หากไม่มีคุกกี้ เซิร์ฟเวอร์จะตรวจสอบค่าของส่วนหัวคำขอ Sec-Fetch-Storage-Access หากตั้งค่านี้เป็น inactive เซิร์ฟเวอร์จะตอบกลับด้วยส่วนหัว Activate-Storage-Access: retry ซึ่งบ่งบอกว่าควรลองส่งคำขออ��กครั้งโดยให้สิทธิ์เข้าถึงพื้นที่เก็บข้อมูล หากไม่มีคุกกี้และส่วนหัว Sec-Fetch-Storage-Access ไม่มีค่า "ไม่ใช้งาน" รูปภาพจะไม่โหลด

ขั้นตอนการส่งผ่านข้อมูลส่วนหัว HTTP

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

เมื่อใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูล การเข้าชมหน้าเว็บต่อๆ ไปจะทริกเกอร์ขั้นตอนต่อไปนี้

1. ผู้ใช้เข้าชม website.example ที่มี calendar.example ฝังอยู่อีกครั้ง การดึงข้อมูลนี้ยังไม่มีสิทธิ์เข้าถึงคุกกี้ เช่นเดียวกับก่อนหน้านี้ อย่างไรก็ตาม ผู้ใช้เคยให้สิทธิ์ storage-access ไว้ก่อนหน้านี้ และการดึงข้อมูลมีส่วนหัว Sec-Fetch-Storage-Access: inactive เพื่อระบุว่ามีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน แต่ไม่ได้ใช้งาน
2. เซิร์ฟเวอร์ calendar.example จะตอบกลับด้วยส่วนหัว Activate-Storage-Access: retry; allowed-origin="<origin>" (ในกรณีนี้ <origin> จะเป็น https://website.example) เพื่อระบุว่าการดึงข้อมูลทรัพยากรต้องใช้คุกกี้ที่ไม่ได้แบ่งพาร์ติชันซึ่งมีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล
3. เบราว์เซอร์จะลองส่งคำขออีกครั้ง โดยครั้งนี้จะรวมคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน (เปิดใช้งานสิทธิ์ storage-access สำหรับการดึงข้อมูลนี้)
4. เซิร์ฟเวอร์ calendar.example จะตอบกลับด้วยเนื้อหา iframe ที่ปรับเปลี่ยนในแบบของคุณ การตอบกลับจะมีส่วนหัว Activate-Storage-Access: load เพื่อระบุว่าเบราว์เซอร์ควรโหลดเนื้อหาโดยเปิดใช้งานสิทธิ์ storage-access (กล่าวคือ โหลดด้วยการเข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชัน เหมือนกับว่ามีการเรียกใช้ document.requestStorageAccess())
5. User Agent จะโหลดเนื้อหา iframe ที่มีสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันโดยใช้สิทธิ์การเข้าถึงพื้นที่เก็บข้อมูล หลังจากขั้นตอนนี้ วิดเจ็ตจะทํางานได้ตามที่คาดไว้

อัปเดตโซลูชัน

เมื่อใช้ฟีเจอร์ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูล คุณอาจต้องอัปเดตโค้ดใน 2 กรณีต่อไปนี้

1. คุณใช้ SAA และต้องการเพิ่มประสิทธิภาพด้วยตรรกะส่วนหัว
2. คุณมีการตรวจสอบหรือตรรกะที่ขึ้นอยู่กับว่าคำขอในเซิร์ฟเวอร์ของคุณมีส่วนหัว Origin หรือไม่

ใช้ตรรกะส่วนหัว SAA

หากต้องการใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลในโซลูชัน คุณต้องอัปเดตโซลูชัน สมมติว่าคุณเป็นเจ้าของ calendar.example โค้ดวิดเจ็ตต้องมีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลเพื่อให้ website.example โหลดวิดเจ็ต calendar.example ที่ปรับเปลี่ยนในแบบของคุณได้

ฝั่งไคลเอ็นต์

ฟีเจอร์ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลไม่จําเป็นต้องอัปเดตโค้ดฝั่งไคลเอ็นต์สําหรับโซลูชันที่มีอยู่ อ่านเอกสารประกอบเพื่อดูวิธีติดตั้งใช้งาน SAA

ฝั่งเซิร์ฟเวอร์

คุณสามารถใช้ส่วนหัวใหม่ฝั่งเซิร์ฟเวอร์ได้ ดังนี้

app.get('/cookie-access-endpoint', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

ดูเดโมเพื่อดูว่าโซลูชันนี้ทํางานอย่างไร

อัปเดตตรรกะส่วนหัวของต้นทาง

เมื่อใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูล Chrome จะส่งส่วนหัว Origin ในคำขอมากกว่าที่เคย ซึ่งอาจส่งผลต่อตรรกะฝั่งเซิร์ฟเวอร์หากอาศัยส่วนหัว Origin ที่มีอยู่ในคำขอบางประเภทเท่านั้น (เช่น คำขอที่ CORS กำหนด)

คุณต้องตรวจสอบโค้ดฝั่งเซิร์ฟเวอร์เพื่อหลีกเลี่ยงปัญหาที่อาจเกิดขึ้น

• ตรวจสอบการตรวจสอบหรือตรรกะใดๆ ที่ขึ้นอยู่กับการมีส่วนหัว Origin
• อัปเดตโค้ดให้จัดการกับส่วนหัว Origin ในกรณีที่พบบ่อยขึ้น

ข้อดีหลักๆ

เราขอแนะนำให้ใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลซึ่งเป็นวิธีที่มีประสิทธิภาพมากกว่าในการใช้ SAA โดยรวมแล้ว การเปลี่ยนแปลงนี้มีการปรับปรุงหลายประการ ดังนี้

• การรองรับการฝังที่ไม่ใช่ iframe: เปิดใช้ SAA สําหรับทรัพยากรที่หลากหลายมากขึ้น
• การใช้เครือข่ายลดลง: คำขอน้อยลงและเพย์โหลดมีขนาดเล็กลง
• การใช้งาน CPU ลดลง: การประมวลผล JavaScript น้อยลง
• UX ที่ดีขึ้น: กำจัดการโหลดขั้นกลางที่รบกวน

เข้าร่วมช่วงทดลองใช้จากต้นทาง

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

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

1. ไปที่หน้าการลงทะเบียนช่วงทดลองใช้ส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลจากต้นทาง
2. ทำตามวิธีการเกี่ยวกับการเข้าร่วมการทดลองใช้เวอร์ชันต้นฉบับ

ทดสอบในเครื่อง

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

ทำตามขั้นตอนต่อไปนี้เพื่อกำหนดค่าอินสแตนซ์ Chrome

1. เปิดใช้ Flag ของ Chrome ใน chrome://flags/#storage-access-headers
2. รีสตาร์ท Chrome เพื่อให้การเปลี่ยนแปลงมีผล

มีส่วนร่วมและแชร์ความคิดเห็น

หากมีความคิดเห็นหรือพบปัญหา คุณสามารถยื่นปัญหาได้ นอกจากนี้ คุณยังดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัวการเข้าถึงพื้นที่เก็บข้อมูลได้ในคำอธิบายของ GitHub