Reporting API เวอร์ชันใหม่พร้อมใช้งานแล้ว เนื่องจากมีความเป็นส่วนตัวมากกว่าและมีโอกาสที่จะได้รับการสนับสนุนในเบราว์เซอร์ต่างๆ มากกว่า
Reporting API จะแจ้งให้คุณทราบเกี่ยวกับข้อผิดพลาดที่เกิดขึ้นในเว็บไซต์เมื่อผู้เข้าชมใช้งาน ซึ่งจะช่วยให้คุณเห็นการแทรกแซงเบราว์เซอร์ การขัดข้องของเบราว์เซอร์ การละเมิดนโยบายรักษาความปลอดภัยเนื้อหา การละเมิด COOP/COEP คำเตือนการเลิกใช้งาน และอื่นๆ
Reporting API เวอร์ชันใหม่พร้อมใช้งานแล้ว API ใหม่นี้มีความกะทัดรัดมากขึ้นและมีแนวโน้มที่เบราว์เซอร์ต่างๆ จะรองรับ
สรุป
นักพัฒนาเว็บไซต์
หากมีฟังก์ชันการรายงานสําหรับเว็บไซต์อยู่แล้ว ให้ย้ายข้อมูลไปยัง v1 โดยใช้ส่วนหัวใหม่ (Reporting-Endpoints) แต่เก็บส่วนหัวเดิมไว้ใช้อีกสักระยะ (Report-To) ดูการย้ายข้อมูล: ตัวอย่างโค้ด
หากเพิ่งเพิ่มฟังก์ชันการรายงานลงในเว็บไซต์ ให้ใช้เฉพาะส่วนหัวใหม่ (Reporting-Endpoints)
⚠️ ไม่ว่าจะในกรณีใด โปรดตั้งค่าส่วนหัว 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 รองรับรายงานประเภทเดียวกัน โดยมีข้อยกเว้น 1 ข้อคือ v1 ไม่รองรับรายงานข้อผิดพลาดของเครือข่าย อ่านเพิ่มเติมในขั้นตอนการย้ายข้อมูล
- v0 ยังไม่รองรับและจะไม่รองรับในเบราว์เซอร์ต่างๆ ส่วน v1 มีแนวโน้มที่จะรองรับในเบราว์เซอร์หลายรุ่นในอนาคต
สิ่งที่ยังคงเหมือนเดิม
- รูปแบบและโครงสร้างของรายงานจะไม่มีการเปลี่ยนแปลง
- คำขอที่เบราว์เซอร์ส่งไปยังปลายทางจะยังคงเป็นคำขอ
POSTของContent-typeapplication/reports+json - การแมปปลายทางบางรายการกับรายงานบางประเภทใช้ได้ทั้งใน v0 และ v1
- บทบาทของปลายทาง
defaultจะไม่มีการเปลี่ยนแปลง Reporting API เวอร์ชัน 1 ไม่มีผลต่อ
ReportingObserverReportingObserverจะยังคงมีสิทธิ์เข้าถึงรายงานที่สังเกตได้ทั้งหมดและรูปแบบของรายงานจะเหมือนกัน
ความแตกต่างทั้งหมดระหว่าง v0 กับ v1
Reporting API เดิม (v0)Report-To ส่วนหัว |
Reporting API ใหม่ (v1)Reporting-Endpoints ส่วนหัว |
|
|---|---|---|
| การสนับสนุนเบราว์เซอร์ | Chrome 69 ขึ้นไปและ Edge 69 ขึ้นไป | Chrome 96 ขึ้นไปและ Edge 96 ขึ้นไป Firefox รองรับ Safari ไม่คัดค้าน ดูสัญญาณเบราว์เซอร์ |
| ปลายทาง | ส่งรายงานไปยังเครื่องมือรวบรวมรายงานหลายรายการ (URL หลายรายการที่กําหนดไว้ต่อกลุ่มอุปกรณ์ปลายทาง) | ส่งรายงานไปยังเครื่องมือรวบรวมรายงานที่เจาะจง (กำหนด URL ได้เพียง URL เดียวต่อปลายทาง) |
| แพลตฟอร์ม API | ใช้ส่วนหัว `Report-To` เพื่อกําหนดค่ากลุ่มอุปกรณ์ปลายทางที่มีชื่อ |
ใช้ส่วนหัว `Reporting-Endpoints` เพื่อกําหนดค่าปลายทางที่มีชื่อ |
| ประเภทรายงานที่สร้างได้ผ่าน API นี้ |
|
ไม่มีการเปลี่ยนแปลง ยกเว้นการบันทึกข้อผิดพลาดของเครือข่าย (NEL): Reporting API เวอร์ชันใหม่ (v1) ไม่รองรับ |
| ขอบเขตรายงาน | ต้นทางของคุณเป็นเจ้าของเอกสารนั้น ส่วนหัว Report-To ของเอกสารจะส่งผลต่อเอกสาร (หน้า) อื่นๆ จากต้นทางนั้น
ช่อง url ของรายงานจะยังคงแตกต่างกันไปตามเอกสาร
|
เอกสาร ส่วนหัว Reporting-Endpoints ของเอกสารจะมีผลกับเอกสารนั้นๆ เท่านั้น
ช่อง url ของรายงานจะยังคงแตกต่างกันไปตามเอกสาร
|
| การแยกรายงาน (การแยกกลุ่ม) | ระบบจะจัดกลุ่มเอกสาร (หน้าเว็บ) หรือเว็บไซต์/ต้นทางต่างๆ ที่สร้างรายงานในเวลาใกล้เคียงกันและมีปลายทางการรายงานเดียวกันไว้ด้วยกัน โดยระบบจะส่งเอกสารเหล่านั้นในข้อความเดียวกันไปยังปลายทางการรายงาน |
|
| การรองรับการจัดสรรภาระงาน / ลําดับความสําคัญ | ใช่ | ไม่ |
นักพัฒนาแอปเกี่ยวกับอุปกรณ์ปลายทาง: คาดว่าจะมีการเข้าชมมากขึ้น
หากคุณตั้งค่าเซิร์ฟเวอร์ของคุณเองเป็นปลายทางการรายงาน หรือกำลังพัฒนาหรือดูแลรักษาเครื่องมือรวบรวมรายงานเป็นบริการ คุณอาจเห็นว่ามีการเข้าชมปลายทางนั้นมากขึ้น
เนื่องจากรายงานไม่ได้จัดกลุ่มกับ Reporting API เวอร์ชัน 1 เหมือนกับที่รายงานจัดกลุ่มกับ Reporting API เวอร์ชัน 0 ดังนั้น เมื่อนักพัฒนาแอปพลิเคชันเริ่มย้ายข้อมูลไปยัง 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) ปัจจุบัน 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ไว้ข้อยกเว้น 1 ข้อ: หากต้องการรายงานการบันทึกข้อผิดพลาดเกี่ยวกับเครือข่าย ให้ใช้
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(เวอร์ชัน 1) ที่ใหม่กว่า การดำเนินการนี้มีการสนับสนุนใน Chrome และ Edge เท่านั้น คำขอรายงานมีรูปแบบเดียวกับคำขอ Reporting API อื่นๆ และมีประเภทเนื้อหาเดียวกันapplication/reports+json
เราไม่แนะนำให้ใช้แนวทางแรก (report-uri เท่านั้น) อีกต่อไป แต่การใช้แนวทางที่ 2 มีข้อดีอยู่ 2-3 ข้อ โดยเฉพาะอย่างยิ่ง จะช่วยให้คุณใช้วิธีเดียวในการตั้งค่าการรายงานสําหรับรายงานทุกประเภท รวมถึงตั้งค่าปลายทางทั่วไปได้ (เนื่องจากคําขอรายงานทั้งหมดที่สร้างผ่าน 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) คุณอาจต้องปรับแต่ง 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 เวอร์ชัน 1 แล้ว
โปรดทราบว่าในเวอร์ชัน 1 คุณยังคงส่งประเภทรายงานที่เฉพาะเจาะจงไปยังปลายทางที่เฉพาะเจาะจงได้ แต่คุณจะมีได้เพียง 1 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 ที่ให้การตรวจสอบและคำแนะนำเกี่ยวกับบทความนี้