Reporting API เวอร์ชันใหม่พร้อมใช้งานแล้ว มีความเป็นส่วนตัวมากขึ้นและมีแนวโน้มที่จะได้รับการรองรับในเบราว์เซอร์ต่างๆ มากขึ้น
Reporting API จะแจ้งให้คุณทราบเกี่ยวกับข้อผิดพลาดที่เกิดขึ้นทั่วทั้งเว็บไซต์เมื่อผู้เข้าชมใช้งาน ซึ่งจะช่วยให้คุณเห็นการแทรกแซงของเบราว์เซอร์ เบราว์เซอร์ขัดข้อง การละเมิดนโยบายรักษาความปลอดภัยเนื้อหา การละเมิด COOP/COEP คำเตือนการเลิกใช้งาน และอื่นๆ
Reporting API เวอร์ชันใหม่พร้อมใช้งานแล้ว API ใหม่นี้มีขนาดเล็กลงและมีแนวโน้มที่จะ รองรับในเบราว์เซอร์ต่างๆ มากขึ้น
สรุป
นักพัฒนาเว็บไซต์
หากมีฟังก์ชันการรายงานสำหรับเว็บไซต์อยู่แล้ว ให้ย้ายข้อมูลไปยัง v1 โดยใช้ส่วนหัวใหม่
(Reporting-Endpoints) แต่เก็บส่วนหัวเดิมไว้สักระยะ (Report-To)
ดูการย้ายข้อมูล: โค้ดตัวอย่าง
หากคุณเพิ่งเพิ่มฟังก์ชันการรายงานลงในเว็บไซต์ ให้ใช้เฉพาะส่วนหัวใหม่
(Reporting-Endpoints)
⚠️ ในทั้ง 2 กรณี ให้ตรวจสอบว่าได้ตั้งค่าส่วนหัว Reporting-Endpoints ในการตอบกลับทั้งหมดที่อาจสร้างรายงาน
นักพัฒนาบริการรายงาน
หากคุณดูแลบริการปลายทางหรือดำเนินการด้วยตนเอง โปรดคาดการณ์ว่าการรับส่งข้อมูลจะเพิ่มขึ้นเมื่อคุณ หรือนักพัฒนาซอฟต์แวร์ภายนอกย้ายข้อมูลไปยัง Reporting API v1 (ส่วนหัว Reporting-Endpoints)
โปรดอ่านต่อเพื่อดูรายละเอียดและตัวอย่างโค้ด
การบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย
เราจะพัฒนากลไกใหม่สำหรับการบันทึกข้อผิดพลาดของเครือข่าย เมื่อพร้อมใช้งานแล้ว ให้เปลี่ยนจาก Reporting API v0 ไปใช้กลไกใหม่นั้น
การสาธิตและโค้ด
- เว็บไซต์สาธิต: Reporting API ใหม่ (v1)
- โค้ดสำหรับเว็บไซต์เดโม
ความแตกต่างระหว่าง v0 กับ v1
สิ่งที่จะเปลี่ยนแปลง
- API ของโมเดลนี้แตกต่างกัน
Report-To: { group: "main-endpoint", "max_age": 86400, "endpoints": [ { "url": ... }, { "url": ... }] }, { group: "default-endpoint", "max_age": 86400, "endpoints": [ { "url": ... }, { "url": ... }] } Document-Policy: ...; report-to main-endpoint
{0 ใช้ส่วนหัว Report-To เพื่อกำหนดค่ากลุ่มอุปกรณ์ปลายทางที่มีชื่อ และใช้คำสั่ง report-to ในส่วนหัวอื่นๆ เพื่ออ้างอิงกลุ่มอุปกรณ์ปลายทางเหล่านี้
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default" Document-Policy: ...; report-to main-endpoint
v1 ใช้ส่วนหัว Reporting-Endpoints เพื่อกำหนดค่าปลายทางที่มีชื่อ เช่นเดียวกับ v0 โดยจะใช้คำสั่ง report-to ในส่วนหัวอื่นๆ เพื่ออ้างอิงกลุ่มปลายทางเหล่านี้
- ขอบเขตของรายงานแตกต่างกัน
ใน v0 คุณจะตั้งค่าปลายทางการรายงานในคำตอบบางรายการได้เท่านั้น เอกสาร (หน้า) อื่นๆ ในต้นทางนั้นจะใช้ปลายทางโดยรอบเหล่านี้โดยอัตโนมัติ
ใน v1 คุณต้องตั้งค่าส่วนหัว Reporting-Endpoints ในการตอบกลับทั้งหมดที่อาจสร้างรายงาน
- ทั้ง 2 API รองรับรายงานประเภทเดียวกัน ยกเว้น v1 ที่ไม่รองรับรายงานข้อผิดพลาดของเครือข่าย ดูข้อมูลเพิ่มเติมได้ในขั้นตอนการย้ายข้อมูล
- v0 ไม่รองรับและจะไม่รองรับในเบราว์เซอร์ต่างๆ ส่วน v1 มีแนวโน้มที่จะรองรับใน เบราว์เซอร์หลายๆ ตัวในอนาคต
สิ่งที่ยังคงเหมือนเดิม
- รูปแบบและโครงสร้างของรายงานจะไม่มีการเปลี่ยนแปลง
- คำขอที่เบราว์เซอร์ส่งไปยังปลายทางยังคงเป็นคำขอ
POSTของContent-typeapplication/reports+json - ทั้ง v0 และ v1 รองรับการแมปปลายทางบางอย่างกับรายงานบางประเภท
- บทบาทของปลายทาง
defaultจะไม่มีการเปลี่ยนแปลง Reporting API v1 จะไม่มีผลต่อ
ReportingObserverReportingObserverจะยังคงได้รับสิทธิ์เข้าถึงรายงานที่สังเกตได้ทั้งหมด และรูปแบบของรายงานจะเหมือนเดิม
ความแตกต่างทั้งหมดระหว่าง v0 กับ v1
Legacy Reporting API (v0)Report-To header |
Reporting API ใหม่ (v1)Reporting-Endpoints ส่วนหัว |
|
|---|---|---|
| การสนับสนุนเบราว์เซอร์ | Chrome 69 ขึ้นไปและ Edge 69 ขึ้นไป | Chrome 96 ขึ้นไปและ Edge 96 ขึ้นไป Firefox รองรับ Safari ไม่คัดค้าน ดูสัญญาณเบราว์เซอร์ |
| ปลายทาง | ส่งรายงานไปยังเครื่องมือรวบรวมรายงานหลายรายการ (กำหนด URL หลายรายการต่อกลุ่มปลายทาง) | ส่งรายงานไปยังผู้รวบรวมรายงานที่เฉพาะเจาะจง (กำหนด URL ได้เพียง 1 รายการต่ออุปกรณ์ปลายทาง) |
| แพลตฟอร์ม API | ใช้ส่วนหัว `Report-To` เพื่อกำหนดค่ากลุ่มอุปกรณ์ปลายทางที่มีชื่อ |
ใช้ส่วนหัว `Reporting-Endpoints` เพื่อกำหนดค่าปลายทางที่มีชื่อ |
| ประเภทรายงานที่สร้างผ่าน API นี้ได้ |
|
ไม่มีการเปลี่ยนแปลง ยกเว้นการบันทึกข้อผิดพลาดของเครือข่าย (NEL) ซึ่งไม่รองรับใน Reporting API ใหม่ (v1) |
| ขอบเขตของรายงาน | ต้นทางของคุณเป็นเจ้าของเอกสารนั้นReport-Toส่วนหัวของเอกสารจะส่งผลต่อเอกสาร (หน้า) อื่นๆ จากแหล่งที่มานั้น
url ของรายงานยังคงแตกต่างกันไปตามเอกสาร
|
เอกสาร ส่วนหัว Reporting-Endpoints ของเอกสารจะมีผลกับเอกสารนั้นเท่านั้น
url ของรายงานยังคงแตกต่างกันไปตามเอกสาร
|
| การแยกรายงาน (การจัดกลุ่ม) | เอกสาร (หน้า) หรือเว็บไซต์/ต้นทางที่แตกต่างกันซึ่งสร้างรายงานในช่วงเวลาเดียวกันและมีปลายทางการรายงานเดียวกันจะได้รับการจัดกลุ่มไว้ด้วยกัน โดยจะส่งในข้อความเดียวกันไปยังปลายทางการรายงาน |
|
| รองรับการจัดสรรภาระงาน / ลำดับความสำคัญ | ใช่ | ไม่ |
นักพัฒนาแอปปลายทาง: คาดว่าจะมีปริมาณการเข้าชมมากขึ้น
หากคุณตั้งค่าเซิร์ฟเวอร์ของคุณเองเป็นปลายทางการรายงาน หรือหากคุณกำลังพัฒนาหรือบำรุงรักษาเครื่องมือรวบรวมรายงานเป็นบริการ ให้คาดการณ์ว่าจะมีปริมาณการเข้าชมปลายทางดังกล่าวมากขึ้น
เนื่องจากรายงานไม่ได้จัดกลุ่มกับ Reporting API v1 เหมือนกับ Reporting API v0 ดังนั้น เมื่อนักพัฒนาแอปพลิเคชันเริ่มย้ายข้อมูลไปยัง Reporting API v1 จำนวนรายงานจะยังคงคล้ายเดิม แต่ปริมาณคำขอไปยังเซิร์ฟเวอร์ปลายทางจะเพิ่มขึ้น
นักพัฒนาแอปพลิเคชัน: ย้ายข้อมูลไปยัง Reporting-Endpoints (v1)
คุณควรทำอย่างไร
การใช้ Reporting API ใหม่ (v1) มีประโยชน์หลายประการ ✅ ดังนี้
- สัญญาณของเบราว์เซอร์เป็นบวก ซึ่งหมายความว่า เราคาดหวังการรองรับข้ามเบราว์เซอร์สำหรับ v1 ได้ (ต่างจาก v0 ที่รองรับเฉพาะใน Chrome และ Edge)
- API มีขนาดเล็กลง
- เรากำลังพัฒนาเครื่องมือเกี่ยวกับ Reporting API (v1) ใหม่
โดยมีข้อควรทราบดังนี้
- หากเว็บไซต์ใช้ Reporting API v0 กับส่วนหัว
Report-Toอยู่แล้ว ให้ย้ายข้อมูลไปยัง Reporting API v1 (ดูขั้นตอนการย้ายข้อมูล) หากเว็บไซต์ของคุณใช้ฟังก์ชันการรายงานการละเมิดนโยบายรักษาความปลอดภัยเนื้อหาอยู่แล้ว โปรดดูขั้นตอนการย้ายข้อมูลสำหรับการรายงาน CSP โดยเฉพาะ - หากเว็บไซต์ยังไม่ได้ใช้ Reporting API และคุณกำลังเพิ่มฟังก์ชันการรายงาน ให้ทำดังนี้
ใช้ Reporting API ใหม่ (v1) (ส่วนหัว
Reporting-Endpoints) มีข้อยกเว้นหนึ่งข้อสำหรับReport-To(v0): หากคุณต้องการใช้การบันทึกข้อผิดพลาดของเครือข่าย ให้ใช้Report-To(v0) ขณะนี้ Reporting API v1 ไม่รองรับการบันทึกข้อผิดพลาดของเครือข่าย เราจะพัฒนากลไกใหม่สำหรับการบันทึกข้อผิดพลาดของเครือข่าย จนกว่าจะพร้อมใช้งาน ให้ใช้ Reporting API v0 หากต้องการบันทึกข้อผิดพลาดของเครือข่าย ควบคู่ไปกับรายงานประเภทอื่นๆ ให้ใช้Report-To(v0) และReporting-Endpoints(v1) ทั้ง 2 รายการ v0 จะให้การบันทึกข้อผิดพลาดของเครือข่าย และ v1 จะให้รายงานประเภทอื่นๆ ทั้งหมด
ขั้นตอนการย้ายโปรเจ็กต์
เป้าหมายในการย้ายข้อมูลครั้งนี้คือไม่ให้รายงานที่คุณเคยได้รับใน v0 หายไป
ขั้นตอนที่ 1 (ทำเลย): ใช้ทั้งส่วนหัว
Report-To(v0) และReporting-Endpoints(v1)ซึ่งจะช่วยให้คุณได้รับสิ่งต่อไปนี้
- รายงานจากไคลเอ็นต์ Chrome และ Edge เวอร์ชันใหม่กว่าด้วย
Reporting-Endpoints(v1) - รายงานจากไคลเอ็นต์ Chrome และ Edge รุ่นเก่ากว่าด้วย
Report-To(v0)
อินสแตนซ์ของเบราว์เซอร์ที่รองรับ
Reporting-Endpointsจะใช้Reporting-Endpointsและ อินสแตนซ์ที่ไม่รองรับจะกลับไปใช้Report-Toรูปแบบคำขอและรายงานจะเหมือนกันสำหรับ v0 และ v1- รายงานจากไคลเอ็นต์ Chrome และ Edge เวอร์ชันใหม่กว่าด้วย
ขั้นตอนที่ 2 (ทำเลย): ตรวจสอบว่าได้ตั้งค่าส่วนหัว
Reporting-Endpointsในการตอบกลับทั้งหมดที่อาจสร้างรายงานใน v0 คุณสามารถเลือกตั้งค่าปลายทางการรายงานในบางการตอบกลับเท่านั้น และเอกสารอื่นๆ (หน้าเว็บ) ในต้นทางนั้นจะใช้ปลายทาง "โดยรอบ" นี้ ใน v1 คุณต้องตั้งค่าส่วนหัว
Reporting-Endpointsในการตอบกลับทั้งหมดที่อาจสร้างรายงานเนื่องจากความแตกต่างในการกำหนดขอบเขตขั้นตอนที่ 3 (เริ่มในภายหลัง): เมื่อผู้ใช้ทั้งหมดหรือส่วนใหญ่ได้อัปเดตเป็น Chrome หรือ Edge เวอร์ชันใหม่กว่า (96 ขึ้นไป) แล้ว ให้นำ
Report-To(v0) ออกและเก็บเฉพาะReporting-Endpointsไว้ข้อยกเว้นอย่างหนึ่งคือ หากคุณต้องการรายงานการบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย ให้เก็บ
Report-Toไว้จนกว่าจะมีกลไกใหม่ สำหรับการบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย
ดูตัวอย่างโค้ดได้ในคู่มือการย้ายข้อมูล
ขั้นตอนการย้ายข้อมูลสำหรับการรายงาน CSP
การกำหนดค่ารายงานการละเมิด Content-Security-Policy ทำได้ 2 วิธีดังนี้
- มีเพียงส่วนหัว CSP ผ่านคําสั่ง
report-uriซึ่งรองรับเบราว์เซอร์อย่างกว้างขวางใน Chrome, Firefox, Safari และ Edge ระบบจะส่งรายงานพร้อมประเภทเนื้อหาapplication/csp-reportและมีรูปแบบที่เฉพาะเจาะจงสำหรับ CSP รายงานเหล่านี้เรียกว่า "รายงาน CSP ระดับ 2" และไม่ได้อิงตาม Reporting API - โดยใช้ Reporting API ผ่านส่วนหัว
Report-To(เดิม) หรือReporting-Endpoints(v1) ที่ใหม่กว่า โดยรองรับเฉพาะใน Chrome และ Edge คำขอรายงานมีรูปแบบเดียวกับคำขอ Reporting API อื่นๆ และมี Content-Type เดียวกันapplication/reports+json
ไม่แนะนำให้ใช้วิธีแรก (เฉพาะ report-uri) อีกต่อไป และการใช้วิธีที่ 2 มีข้อดีบางประการ โดยเฉพาะอย่างยิ่ง API นี้ช่วยให้คุณใช้วิธีเดียวในการตั้งค่าการรายงานสำหรับรายงานทุกประเภท รวมถึงตั้งค่าปลายทางทั่วไปได้ (เนื่องจากคำขอรายงานทั้งหมดที่สร้างผ่าน Reporting API⏤CSP และอื่นๆ⏤มีรูปแบบเดียวกัน application/reports+json
อย่างไรก็ตาม มีเพียงไม่กี่เบราว์เซอร์ที่รองรับ report-to
ดังนั้นเราขอแนะนำให้คุณใช้ report-uri ควบคู่ไปกับแนวทางการใช้ Reporting API (Report-To
หรือสูงกว่า Reporting-Endpoints) เพื่อรับรายงานการละเมิด CSP จากเบราว์เซอร์หลายรายการ ในเบราว์เซอร์ที่รู้จัก report-uri และ report-to ระบบจะไม่สนใจ report-uri หากมี report-to
ในเบราว์เซอร์ที่รู้จักเฉพาะ report-uri ระบบจะพิจารณาเฉพาะ report-uri เท่านั้น
ขั้นตอนที่ 1 (ทำเลย): หากยังไม่ได้เพิ่ม ให้เพิ่ม
report-toข้างreport-uriเบราว์เซอร์ที่รองรับเฉพาะreport-uri(Firefox) จะใช้report-uriและเบราว์เซอร์ที่รองรับreport-to(Chrome, Edge) ด้วยจะใช้report-toหากต้องการระบุอุปกรณ์ปลายทางที่มีชื่อซึ่งคุณจะใช้ ในreport-toให้ใช้ทั้งส่วนหัวReport-ToและReporting-Endpointsซึ่งจะช่วยให้คุณได้รับรายงานจากทั้งไคลเอ็นต์ Chrome และ Edge เวอร์ชันเก่าและใหม่ขั้นตอนที่ 3 (เริ่มในภายหลัง): เมื่อผู้ใช้ทั้งหมดหรือส่วนใหญ่ได้อัปเดตเป็น Chrome หรือ Edge เวอร์ชันใหม่กว่า (96 ขึ้นไป) แล้ว ให้นำ
Report-To(v0) ออกและเก็บเฉพาะReporting-Endpointsไว้ เก็บreport-uriไว้เพื่อให้คุณยังคงได้รับรายงานสำหรับเบราว์เซอร์ที่รองรับเฉพาะ
ดูตัวอย่างโค้ดสำหรับขั้นตอนเหล่านี้ได้ในการย้ายข้อมูลการรายงาน CSP
การย้ายข้อมูล: ตัวอย่างโค้ด
ภาพรวม
หากคุณใช้ Reporting API (v0) แบบเดิมเพื่อรับรายงานการละเมิดสำหรับ COOP
(Cross-Origin-Opener-Policy ส่วนหัว), COEP (Cross-Origin-Embedder-Policy) หรือนโยบายเอกสาร
(Document-Policy ส่วนหัว) คุณไม่จำเป็นต้องเปลี่ยนส่วนหัวของนโยบายเหล่านี้เมื่อย้ายข้อมูลไปยัง Reporting API v1 สิ่งที่คุณต้องทำคือย้ายข้อมูลจากส่วนหัว Report-To เดิมไปยังส่วนหัว Reporting-Endpoints ใหม่
หากคุณใช้ Reporting API เดิม (v0) เพื่อรับรายงานการละเมิดสำหรับ CSP
(Content-Security-Policy header) คุณอาจต้องปรับ Content-Security-Policy เป็นส่วนหนึ่งของการย้ายข้อมูลไปยัง Reporting API ใหม่ (v1)
การย้ายข้อมูลพื้นฐาน
Report-To: { group: "main-endpoint", "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "endpoints": [ { "url": "https://reports.example/default" }] }Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default" Report-To: { group: "main-endpoint", "max_age": 86400, "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "max_age": 86400, "endpoints": [ { "url": "https://reports.example/default" }] }
หากเว็บไซต์มีฟังก์ชันการรายงานอยู่แล้ว ให้เก็บ Report-To ไว้ชั่วคราวเท่านั้น
(จนกว่าไคลเอ็นต์ Chrome และ Edge ส่วนใหญ่จะได้รับการอัปเดต) เพื่อไม่ให้รายงานสูญหาย
หากต้องการการบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย ให้ใช้ Report-To จนกว่าจะมีการแทนที่การบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"นี่คือลักษณะโค้ดของคุณในอนาคต เมื่อไคลเอ็นต์ Chrome และ Edge ส่วนใหญ่ได้รับการอัปเดตและรองรับ API v1 แล้ว
โปรดทราบว่าใน v1 คุณยังคงส่งประเภทรายงานที่เฉพาะเจาะจงไปยังอุปกรณ์ปลายทางที่เฉพาะเจาะจงได้ แต่คุณมี URL ได้เพียงรายการเดียวต่อปลายทาง
สังเกตการณ์ทุกหน้า
app.get("/", (request, response) => { response.set("Report-To", …) response.render(...) }); app.get("/page1", (request, response) => { response.render(...) });
ใน v0 คุณจะตั้งค่าปลายทางการรายงานในคำตอบบางรายการได้เท่านั้น เอกสาร (หน้า) อื่นๆ ในต้นทางนั้นจะใช้ปลายทางโดยรอบเหล่านี้โดยอัตโนมัติ ในที่นี้ ระบบจะใช้ปลายทางที่ตั้งค่าไว้สำหรับ "/" กับคำตอบทั้งหมด เช่น สำหรับ page1
// Use a middleware to set the reporting endpoint(s) for *all* requests. app.use(function(request, response, next) { response.set("Reporting-Endpoints", …); next(); }); app.get("/", (request, response) => { response.render(...) }); app.get("/page1", (request, response) => { response.render(...) });
ใน v1 คุณต้องตั้งค่าส่วนหัว Reporting-Endpoints ในการตอบกลับทั้งหมด
ที่อาจสร้างรายงาน
การย้ายข้อมูลการรายงาน CSP
Content-Security-Policy: ...; report-uri https://reports.example/mainไม่แนะนำให้ใช้เฉพาะ report-uri อีกต่อไป
หากรหัสมีลักษณะเหมือนด้านบน ให้ย้ายข้อมูล ดูตัวอย่างโค้ดใหม่ด้านล่าง (สีเขียว)
Content-Security-Policy: ...; report-uri https://reports.example/main; report-to main-endpoint Report-To: main-endpoint="https://reports.example/main"
โค้ดนี้ดีกว่า เนื่องจากใช้ report-to ซึ่งเป็นตัวแทนที่ใหม่กว่าของ
report-uri แต่ยังคงมี report-uri ไว้เพื่อความเข้ากันได้แบบย้อนหลัง เนื่องจากเบราว์เซอร์บางตัวไม่รองรับ
report-to
แต่รองรับ
report-uri
แต่เราสามารถปรับปรุงได้โดยใช้โค้ดนี้ซึ่งใช้ Reporting API v0 (ส่วนหัว Report-To) ย้ายข้อมูลไปยัง v1: ดูตัวอย่าง "โค้ดใหม่" ด้านล่าง (สีเขียว)
Content-Security-Policy: ...; report-uri https://reports.example/main; report-to main-endpoint Reporting-Endpoints: main-endpoint="https://reports.example/main" Report-To: ...
เก็บคำสั่ง report-uri ไว้ข้างคำสั่ง report-to จนกว่าเบราว์เซอร์จะรองรับคำสั่ง report-to
ดูตารางความเข้ากันได้ของเบราว์เซอร์
เก็บ Report-To ไว้ข้าง Reporting-Endpoints ชั่วคราว เมื่อผู้เข้าชม Chrome และ Edge
ส่วนใหญ่ได้อัปเกรดเป็นเบราว์เซอร์เวอร์ชัน 96 ขึ้นไปแล้ว ให้นำ Report-To ออก
อ่านเพิ่มเติม
- ตรวจสอบเว็บแอปพลิเคชันด้วย Reporting API (โพสต์หลักเกี่ยวกับ Reporting API)
- ข้อกําหนด: Reporting API เวอร์ชันเดิม (v0)
- ข้อกำหนด: Reporting API ใหม่ (v1)
ขอขอบคุณ Ian Clelland, Eiji Kitamura และ Milica Mihajlija ที่ได้ตรวจสอบและให้คำแนะนำเกี่ยวกับบทความนี้