ผู้ปฏิบัติงานบริการข้ามต้นทาง - การทดสอบการดึงข้อมูลจากต่างประเทศ

Jeff Posnick

ข้อมูลเบื้องต้น

Service Worker ช่วยให้นักพัฒนาเว็บสามารถตอบสนองต่อคำขอเครือข่ายที่ส่งโดยเว็บแอปพลิเคชันของตนได้ ซึ่งช่วยให้แอปพลิเคชันทำงานต่อไปได้แม้ว่าจะออฟไลน์อยู่ รับมือกับ Wi-Fi ที่ไม่เสถียร และใช้งานการโต้ตอบกับแคชที่ซับซ้อน เช่น stale-while-revalidate แต่ที่ผ่านมา Service Worker เชื่อมโยงกับต้นทางที่เฉพาะเจาะจง ในฐานะเจ้าของเว็บแอป คุณมีหน้าที่เขียนและติดตั้งใช้งาน Service Worker เพื่อขัดขวางคําขอเครือข่ายทั้งหมดที่เว็บแอปของคุณส่ง ในโมเดลดังกล่าว แต่ละ Service Worker มีหน้าที่รับผิดชอบในการจัดการคำขอข้ามแหล่งที่มา เช่น คำขอไปยัง API ของบุคคลที่สามหรือคำขอสำหรับแบบอักษรเว็บ

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

การใช้ Service Worker ที่ใช้การดึงข้อมูลภายนอกจะเหมาะกับผู้ให้บริการบริการที่เข้าถึงผ่านคําขอ HTTPS จากเบราว์เซอร์ ลองนึกถึงสถานการณ์ที่คุณให้บริการเวอร์ชันที่ไม่ขึ้นอยู่กับเครือข่าย ซึ่งเบราว์เซอร์สามารถใช้ประโยชน์จากแคชทรัพยากรทั่วไปได้ บริการที่อาจได้รับประโยชน์จากฟีเจอร์นี้รวมถึงแต่ไม่จำกัดเพียงบริการต่อไปนี้

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

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

ข้อกำหนดเบื้องต้น

โทเค็นช่วงทดลองใช้จากต้นทาง

การดึงข้อมูลจากต่างประเทศยังถือว่าอยู่ในขั้นทดลอง เราได้ติดตั้งใช้งานการออกแบบนี้ใน Chrome 54 เป็นการทดลองใช้แหล่งที่มาเพื่อไม่ให้มีการใช้งานก่อนเวลาอันควรก่อนที่ผู้ให้บริการเบราว์เซอร์จะระบุและยอมรับการออกแบบนี้อย่างสมบูรณ์ ตราบใดที่การดึงข้อมูลจากภายนอกยังอยู่ในขั้นทดลอง หากต้องการใช้ฟีเจอร์ใหม่นี้กับบริการที่คุณโฮสต์ คุณจะต้องขอโทเค็นที่มีขอบเขตไปยังต้นทางที่เฉพาะเจาะจงของบริการ คุณควรใส่โทเค็นเป็นส่วนหัวการตอบกลับ HTTP ในคําขอข้ามโดเมนทั้งหมดสําหรับทรัพยากรที่คุณต้องการจัดการผ่านการดึงข้อมูลภายนอก รวมถึงในการตอบกลับสําหรับทรัพยากร JavaScript ของ Service Worker ดังนี้

Origin-Trial: token_obtained_from_signup

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

เพื่ออำนวยความสะดวกในการทดสอบการดึงข้อมูลต่างประเทศก่อนที่จะลงทะเบียนโทเค็นการทดลองใช้จากต้นทางอย่างเป็นทางการ คุณสามารถข้ามข้อกำหนดใน Chrome สำหรับคอมพิวเตอร์ท้องถิ่นได้โดยไปที่ chrome://flags/#enable-experimental-web-platform-features แล้วเปิดใช้แฟล็ก "ฟีเจอร์แพลตฟอร์มเว็บแบบทดลอง" โปรดทราบว่าต้องดำเนินการนี้ในทุกอินสแตนซ์ของ Chrome ที่ต้องการใช้ในการทดสอบในเครื่อง แต่หากใช้โทเค็นการทดลองใช้เวอร์ชันที่ใช้งานจริง ฟีเจอร์นี้จะพร้อมให้บริการแก่ผู้ใช้ Chrome ทุกคน

HTTPS

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

การใช้การดึงข้อมูลจากต่างประเทศ

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

การลงทะเบียน Service Worker

ปัญหาแรกที่คุณอาจพบคือวิธีลงทะเบียน Service Worker หากคุณเคยทำงานกับโปรแกรมทำงานของบริการมาก่อน คุณอาจคุ้นเคยกับสิ่งต่อไปนี้

// You can't do this!
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('service-worker.js');
}

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

โซลูชันนี้อยู่ในรูปแบบส่วนหัว HTTP ที่เซิร์ฟเวอร์ของคุณรวมไว้ในการตอบกลับได้

Link: </service-worker.js>; rel="serviceworker"; scope="/"

เรามาแยกส่วนหัวตัวอย่างนี้ออกเป็นคอมโพเนนต์ต่างๆ ซึ่งแต่ละรายการคั่นด้วยอักขระ ;

  • </service-worker.js> เป็นค่าที่ต้องระบุและใช้เพื่อระบุเส้นทางไปยังไฟล์ Service Worker (แทนที่ /service-worker.js ด้วยเส้นทางที่เหมาะสมไปยังสคริปต์) ซึ่งสอดคล้องกับสตริง scriptURL โดยตรง ซึ่งจะส่งผ่านเป็นพารามิเตอร์แรกไปยัง navigator.serviceWorker.register() ค่าต้องอยู่ในอักขระ <> (ตามที่ข้อกำหนดส่วนหัว Link กำหนด) และหากระบุ URL แบบสัมพัทธ์แทน URL แบบสัมบูรณ์ ระบบจะตีความว่า URL นั้นสัมพันธ์กับตำแหน่งของคำตอบ
  • นอกจากนี้ คุณยังต้องใช้ rel="serviceworker" ด้วย และควรรวมไว้โดยไม่จำเป็นต้องปรับแต่ง
  • scope=/ คือการประกาศขอบเขตที่ไม่บังคับ ซึ่งเทียบเท่ากับสตริง options.scope ที่คุณส่งเป็นพารามิเตอร์ที่ 2 ให้กับ navigator.serviceWorker.register() ได้ สําหรับกรณีการใช้งานหลายรายการ คุณจะใช้ขอบเขตเริ่มต้นได้ ดังนั้นจึงไม่ต้องระบุค่านี้ เว้นแต่คุณจะรู้ว่าจําเป็นต้องใช้ ข้อจํากัดเดียวกันเกี่ยวกับขอบเขตสูงสุดที่อนุญาต รวมถึงความสามารถในการผ่อนคลายข้อจํากัดเหล่านั้นผ่านส่วนหัว Service-Worker-Allowed จะมีผลกับการลงทะเบียนส่วนหัว Link

เช่นเดียวกับการลงทะเบียน Service Worker แบบ "ดั้งเดิม" การใช้ส่วนหัว Link จะติดตั้ง Service Worker ที่จะใช้สําหรับคําขอถัดไปที่ส่งไปยังขอบเขตที่ลงทะเบียน ส่วนเนื้อหาของการตอบกลับที่มีส่วนหัวพิเศษจะถูกใช้ตามที่มีอยู่ และพร้อมใช้งานในหน้าเว็บทันทีโดยไม่ต้องรอให้เจ้าหน้าที่บริการต่างประเทศทำการติดตั้งให้เสร็จสิ้น

โปรดทราบว่าขณะนี้การดึงข้อมูลจากภายนอกมีการใช้งานเป็นช่วงทดลองใช้จากต้นทาง คุณจึงต้องใส่ส่วนหัว Origin-Trial ที่ถูกต้องไว้ด้วยนอกเหนือจากส่วนหัวการตอบกลับของลิงก์ ชุดส่วนหัวการตอบกลับขั้นต่ำที่จะเพิ่มเพื่อลงทะเบียน Service Worker สำหรับการดึงข้อมูลต่างประเทศคือ

Link: </service-worker.js>; rel="serviceworker"
Origin-Trial: token_obtained_from_signup

การแก้ไขข้อบกพร่องการลงทะเบียน

ในระหว่างการพัฒนา คุณอาจต้องตรวจสอบว่าติดตั้งและประมวลผลคําขอของ Wapper บริการดึงข้อมูลต่างประเทศอย่างถูกต้อง คุณสามารถตรวจสอบสิ่งต่างๆ ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome เพื่อยืนยันว่าทุกอย่างทำงานได้ตามที่คาดไว้

มีการส่งส่วนหัวการตอบกลับที่เหมาะสมหรือไม่

ในการลงทะเบียน Service Worker การดึงข้อมูลต่างประเทศ คุณต้องตั้งค่าส่วนหัวของลิงก์ในการตอบกลับทรัพยากรที่โฮสต์ในโดเมนของคุณ ตามที่อธิบายไว้ก่อนหน้านี้ในโพสต์นี้ ในระหว่างช่วงทดลองใช้จากต้นทาง และสมมติว่าคุณไม่ได้ตั้งค่า chrome://flags/#enable-experimental-web-platform-features คุณจะต้องตั้งค่าส่วนหัวการตอบกลับ Origin-Trial ด้วย คุณสามารถยืนยันว่าเว็บเซิร์ฟเวอร์กําลังตั้งค่าส่วนหัวเหล่านั้นได้โดยดูที่รายการในแผงเครือข่ายของเครื่องมือสําหรับนักพัฒนาเว็บ

ส่วนหัวที่แสดงในแผงเครือข่าย

Service Worker ของ Foreign Fetch ลงทะเบียนอย่างถูกต้องหรือไม่

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

โปรแกรมทำงานของบริการดึงข้อมูลต่างชาติในแผงแอปพลิเคชัน

เครื่องจัดการเหตุการณ์การติดตั้ง

เมื่อลงทะเบียน Service Worker ของบุคคลที่สามแล้ว Service Worker ดังกล่าวจะมีโอกาสตอบสนองต่อเหตุการณ์ install และ activate เช่นเดียวกับ Service Worker อื่นๆ ซึ่งสามารถใช้ประโยชน์จากเหตุการณ์เหล่านั้นได้ เช่น การสร้างแคชด้วยทรัพยากรที่จําเป็นในระหว่างเหตุการณ์ install หรือตัดแคชที่ล้าสมัยในเหตุการณ์ activate

นอกเหนือจากกิจกรรมการแคชเหตุการณ์ install ตามปกติแล้ว ยังมีขั้นตอนเพิ่มเติมซึ่งจำเป็นในเครื่องจัดการเหตุการณ์ install ของโปรแกรมทำงานของบริการบุคคลที่สาม โค้ดของคุณต้องเรียกใช้ registerForeignFetch() ตามตัวอย่างต่อไปนี้

self.addEventListener('install', event => {
    event.registerForeignFetch({
    scopes: [self.registration.scope], // or some sub-scope
    origins: ['*'] // or ['https://example.com']
    });
});

การกำหนดค่ามี 2 ตัวเลือก ซึ่งต้องดำเนินการทั้ง 2 อย่าง

  • scopes ใช้อาร์เรย์ของสตริงอย่างน้อย 1 สตริง โดยแต่ละสตริงแสดงถึงขอบเขตคำขอที่จะเรียกเหตุการณ์ foreignfetch ให้แสดง แต่เดี๋ยวก่อน คุณอาจกำลังคิดว่าฉันได้กําหนดขอบเขตไว้แล้วระหว่างการลงทะเบียน Service Worker ถูกต้อง ขอบเขตโดยรวมดังกล่าวยังคงเกี่ยวข้องอยู่ แต่ละขอบเขตที่คุณระบุที่นี่ต้องเท่ากับหรือเป็นขอบเขตย่อยของขอบเขตโดยรวมของ Service Worker ข้อจํากัดการกําหนดขอบเขตเพิ่มเติมที่นี่ช่วยให้คุณติดตั้งใช้งาน Service Worker อเนกประสงค์ที่จัดการทั้งเหตุการณ์ fetch ของบุคคลที่หนึ่ง (สําหรับคําขอที่ส่งจากเว็บไซต์ของคุณเอง) และเหตุการณ์ foreignfetch ของบุคคลที่สาม (สําหรับคําขอที่ส่งจากโดเมนอื่น) ได้ และระบุให้ชัดเจนว่าควรทริกเกอร์ foreignfetch เฉพาะชุดย่อยของขอบเขตที่กว้างขึ้นเท่านั้น ในทางปฏิบัติ หากคุณกำลังใช้งาน Service Worker ที่มีไว้สำหรับจัดการเหตุการณ์ foreignfetch ของบุคคลที่สามเท่านั้น คุณจะต้องใช้ขอบเขตที่ชัดเจนเพียงขอบเขตเดียวซึ่งเท่ากับขอบเขตโดยรวมของโปรแกรมทำงานของบริการ ตัวอย่างด้านบนจะทำงานโดยใช้ค่า self.registration.scope
  • origins ยังใช้อาร์เรย์สตริงอย่างน้อย 1 รายการ และให้คุณจํากัดตัวแฮนเดิล foreignfetch ให้ตอบกลับเฉพาะคําขอจากโดเมนที่เฉพาะเจาะจงได้ เช่น หากคุณอนุญาต "https://example.com" อย่างชัดแจ้ง คำขอที่ส่งจากหน้าที่โฮสต์ที่ https://example.com/path/to/page.html สำหรับทรัพยากรที่แสดงจากขอบเขตการดึงข้อมูลภายนอกจะทริกเกอร์ตัวแฮนเดิลการดึงข้อมูลภายนอก แต่คำขอที่ส่งจาก https://random-domain.com/path/to/page.html จะไม่ทริกเกอร์ตัวแฮนเดิล เว้นแต่คุณจะมีเหตุผลเฉพาะในการทริกเกอร์ตรรกะการดึงข้อมูลภายนอกสําหรับชุดย่อยของต้นทางระยะไกลเท่านั้น คุณก็ระบุ '*' เป็นค่าเดียวในอาร์เรย์ได้ และระบบจะอนุญาตต้นทางทั้งหมด

เครื่องจัดการเหตุการณ์ foreignfetch

เมื่อติดตั้ง Service Worker ของบุคคลที่สามและกำหนดค่าผ่าน registerForeignFetch() แล้ว Service Worker ดังกล่าวจะมีโอกาสสกัดกั้นคำขอทรัพยากรย่อยข้ามแหล่งที่มาไปยังเซิร์ฟเวอร์ของคุณซึ่งอยู่ภายในขอบเขตการดึงข้อมูลภายนอก

ในโปรแกรมทำงานของบริการบุคคลที่หนึ่งแบบดั้งเดิม คำขอแต่ละรายการจะทริกเกอร์เหตุการณ์ fetch ที่ผู้ปฏิบัติงานบริการของคุณมีโอกาสตอบกลับ Service Worker ของบุคคลที่สามได้รับโอกาสให้จัดการเหตุการณ์ที่ต่างกันเล็กน้อยซึ่งมีชื่อว่า foreignfetch ตามหลักการแล้ว ทั้ง 2 เหตุการณ์ค่อนข้างคล้ายกันและจะให้โอกาสคุณตรวจสอบคำขอที่เข้ามาใหม่ และให้คุณตอบกลับผ่าน respondWith() หรือไม่ก็ได้

self.addEventListener('foreignfetch', event => {
    // Assume that requestLogic() is a custom function that takes
    // a Request and returns a Promise which resolves with a Response.
    event.respondWith(
    requestLogic(event.request).then(response => {
        return {
        response: response,
        // Omit to origin to return an opaque response.
        // With this set, the client will receive a CORS response.
        origin: event.origin,
        // Omit headers unless you need additional header filtering.
        // With this set, only Content-Type will be exposed.
        headers: ['Content-Type']
        };
    })
    );
});

แม้ว่าแนวคิดจะคล้ายกัน แต่การใช้งานจริงจะแตกต่างกันเล็กน้อยเมื่อเรียกใช้ respondWith() ใน ForeignFetchEvent แทนที่จะระบุเพียง Response (หรือ Promise ที่จับคู่กับ Response) ให้กับ respondWith() เช่นเดียวกับที่ทำกับ FetchEvent คุณต้องส่ง Promise ที่จับคู่กับออบเจ็กต์ที่มีพร็อพเพอร์ตี้ที่เฉพาะเจาะจงไปยัง respondWith() ของ ForeignFetchEvent ดังนี้

  • ต้องระบุ response และต้องตั้งค่าเป็นออบเจ็กต์ Response ซึ่งจะส่งคืนไปยังไคลเอ็นต์ที่ส่งคำขอ หากคุณระบุข้อมูลอื่นที่ไม่ใช่ Response ที่ถูกต้อง คำขอของลูกค้าจะสิ้นสุดลงด้วยข้อผิดพลาดเกี่ยวกับเครือข่าย ซึ่งแตกต่างจากการเรียก respondWith() ภายในตัวแฮนเดิลเหตุการณ์ fetch ตรงที่คุณต้องระบุ Response ที่นี่ ไม่ใช่ Promise ซึ่งจะแสดงผลเป็น Response คุณสามารถสร้างคำตอบผ่านเชนพรอมต์ และส่งเชนนั้นผ่านพารามิเตอร์ไปยัง respondWith() ของ foreignfetch ได้ แต่เชนต้องคลายกับออบเจ็กต์ที่มีการตั้งค่าพร็อพเพอร์ตี้ response เป็นออบเจ็กต์ Response คุณดูการสาธิตนี้ได้ในตัวอย่างโค้ดด้านบน
  • origin เป็นตัวเลือกและจะใช้เพื่อระบุว่าคำตอบที่แสดงผลเป็นแบบทึบหรือไม่ หากไม่ระบุค่านี้ คำตอบจะเป็นแบบทึบ และไคลเอ็นต์จะมีสิทธิ์เข้าถึงเนื้อหาและส่วนหัวของคำตอบแบบจำกัด หากคำขอนั้นสร้างด้วย mode: 'cors' การส่งคืนการตอบสนองที่ไม่ชัดเจนจะถือว่าเป็นข้อผิดพลาด อย่างไรก็ตาม หากคุณระบุค่าสตริงเท่ากับต้นทางของไคลเอ็นต์ระยะไกล (ซึ่งรับได้ผ่าน event.origin) แสดงว่าคุณเลือกที่จะให้การตอบกลับที่เปิดใช้ CORS แก่ไคลเอ็นต์อย่างชัดเจน
  • headers ก็เป็นตัวเลือกเช่นกัน และจะใช้ได้ก็ต่อเมื่อคุณระบุ origin และแสดงผลลัพธ์ CORS ด้วย โดยค่าเริ่มต้น ระบบจะรวมเฉพาะส่วนหัวในรายการส่วนหัวการตอบกลับที่อยู่ในรายการที่ปลอดภัยของ CORS ในการตอบกลับ หากต้องการกรองสิ่งที่แสดงผลเพิ่มเติม ส่วนหัวจะรับรายการชื่อส่วนหัวอย่างน้อย 1 รายการ และใช้รายการดังกล่าวเป็นรายการที่อนุญาตสำหรับส่วนหัวที่จะแสดงในการตอบกลับ ซึ่งจะช่วยให้คุณเลือกใช้ CORS ได้ขณะที่ยังคงป้องกันไม่ให้ไคลเอ็นต์ระยะไกลเข้าถึงส่วนหัวการตอบกลับที่อาจมีความละเอียดอ่อนได้โดยตรง

โปรดทราบว่าเมื่อเรียกใช้ตัวแฮนเดิล foreignfetch ตัวแฮนเดิลจะมีสิทธิ์เข้าถึงข้อมูลเข้าสู่ระบบทั้งหมดและสิทธิ์เข้าถึงแบบรอบข้างของต้นทางที่โฮสต์ Service Worker ในฐานะนักพัฒนาซอฟต์แวร์ที่ใช้งาน Service Worker ที่เปิดใช้การดึงข้อมูลต่างประเทศ คุณมีหน้าที่ตรวจสอบว่าข้อมูลการตอบกลับที่ได้รับสิทธิ์ไม่รั่วไหลจากแหล่งข้อมูลเข้าสู่ระบบเหล่านี้ การกําหนดให้เลือกใช้การตอบกลับ CORS เป็นขั้นตอนหนึ่งในการจํากัดการเปิดเผยโดยไม่ตั้งใจ แต่ในฐานะนักพัฒนาแอป คุณสามารถส่งคําขอ fetch() ภายในตัวแฮนเดิล foreignfetch อย่างชัดเจนซึ่งไม่ใช้ข้อมูลเข้าสู่ระบบโดยนัยได้ผ่านการดำเนินการต่อไปนี้

self.addEventListener('foreignfetch', event => {
    // The new Request will have credentials omitted by default.
    const noCredentialsRequest = new Request(event.request.url);
    event.respondWith(
    // Replace with your own request logic as appropriate.
    fetch(noCredentialsRequest)
        .catch(() => caches.match(noCredentialsRequest))
        .then(response => ({response}))
    );
});

สิ่งที่ควรพิจารณาสำหรับลูกค้า

มีข้อควรพิจารณาเพิ่มเติมบางอย่างที่ส่งผลต่อวิธีที่ผู้ให้บริการการดึงข้อมูลต่างประเทศจัดการคําขอจากลูกค้าของบริการ

ลูกค้าที่มี Service Worker ของบุคคลที่หนึ่งของตนเอง

ไคลเอ็นต์บริการบางรายของคุณอาจมี Service Worker บุคคลที่หนึ่งเป็นของตัวเองอยู่แล้ว ซึ่งมีหน้าที่จัดการคำขอที่มาจากเว็บแอปของตน การดำเนินการดังกล่าวจะส่งผลอย่างไรต่อโปรแกรมทำงานของบริการดึงข้อมูลต่างประเทศซึ่งเป็นบุคคลที่สาม

ตัวแฮนเดิล fetch ใน Service Worker ของบุคคลที่หนึ่งจะได้รับโอกาสแรกในการตอบกลับคำขอทั้งหมดที่มาจากเว็บแอป แม้ว่าจะมี Service Worker บุคคลที่สามที่เปิดใช้ foreignfetch ซึ่งมีขอบเขตที่ครอบคลุมคำขอดังกล่าวก็ตาม แต่ลูกค้าที่มี Service Worker จากบุคคลที่หนึ่งยังคงใช้ประโยชน์จาก Service Worker ดึงข้อมูลต่างประเทศได้

ใน Service Worker ของบุคคลที่หนึ่ง การใช้ fetch() เพื่อดึงข้อมูลข้ามแหล่งที่มาจะทริกเกอร์ Service Worker สำหรับการดึงข้อมูลภายนอกที่เหมาะสม ซึ่งหมายความว่าโค้ดต่อไปนี้สามารถใช้ประโยชน์จากตัวแฮนเดิล foreignfetch

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    // If event.request is under your foreign fetch service worker's
    // scope, this will trigger your foreignfetch handler.
    event.respondWith(fetch(event.request));
});

ในทํานองเดียวกัน หากมีตัวแฮนเดิลการดึงข้อมูลของบุคคลที่หนึ่ง แต่ไม่ได้เรียก event.respondWith() เมื่อจัดการคําขอทรัพยากรข้ามแหล่งที่มา คําขอจะ "ส่งต่อ" ไปยังตัวแฮนเดิล foreignfetch โดยอัตโนมัติ

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    if (event.request.mode === 'same-origin') {
    event.respondWith(localRequestLogic(event.request));
    }

    // Since event.respondWith() isn't called for cross-origin requests,
    // any foreignfetch handlers scoped to the request will get a chance
    // to provide a response.
});

หากตัวแฮนเดิล fetch ของบุคคลที่หนึ่งเรียก event.respondWith() แต่ไม่ได้ใช้ fetch() เพื่อขอทรัพยากรภายใต้ขอบเขตการดึงข้อมูลภายนอก Service Worker สำหรับการดึงข้อมูลภายนอกจะไม่มีสิทธิ์จัดการคําขอ

ลูกค้าที่ไม่มี Service Worker ของตนเอง

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

ประมวลคำถามทั้งหมด: ที่ที่ลูกค้าต้องการคำตอบ

เมื่อพิจารณาข้อมูลข้างต้นแล้ว เราจะจัดลำดับลําดับชั้นของแหล่งที่มาที่ไคลเอ็นต์จะใช้เพื่อค้นหาคําตอบสําหรับคําขอข้ามแหล่งที่มาได้

  1. แฮนเดิล fetch ของ Service Worker ของบุคคลที่หนึ่ง (หากมี)
  2. แฮนเดิล foreignfetch ของ Service Worker ของบุคคลที่สาม (หากมี และสำหรับคำขอข้ามแหล่งที่มาเท่านั้น)
  3. แคช HTTP ของเบราว์เซอร์ (หากมีการตอบกลับใหม่)
  4. เครือข่าย

เบราว์เซอร์จะเริ่มต้นจากด้านบนและจะดูรายการต่อๆ ไปจนกว่าจะพบแหล่งที่มาของการตอบกลับ ทั้งนี้ขึ้นอยู่กับการใช้งาน Service Worker

ดูข้อมูลเพิ่มเติม

ไม่พลาดรับข้อมูลอัปเดต

การใช้งานช่วงทดลองใช้จากต้นทางของ Chrome สำหรับการดึงข้อมูลจากต่างประเทศอาจมีการเปลี่ยนแปลงเมื่อเราจัดการกับความคิดเห็นที่ได้รับจากนักพัฒนาซอฟต์แวร์ เราจะอัปเดตโพสต์นี้อยู่เสมอผ่านการเปลี่ยนแปลงในบทสนทนา และจะทำบันทึกการเปลี่ยนแปลงที่เฉพาะเจาะจงไว้ด้านล่างเมื่อเกิดการเปลี่ยนแปลง นอกจากนี้ เราจะแชร์ข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่สำคัญผ่านบัญชี Twitter ของ @chromiumdev ด้วย