Reporting API v1 पर माइग्रेट करें

Reporting API का नया वर्शन उपलब्ध है. यह ज़्यादा निजी है और ज़्यादातर ब्राउज़र पर काम कर सकती है.

Maud Nalpas
Maud Nalpas
X GitHub

Reporting API, आपको उन गड़बड़ियों के बारे में बताता है जो आपकी साइट पर, विज़िटर के इस्तेमाल करने पर होती हैं. इससे आपको ब्राउज़र के इंटरवेंशन, ब्राउज़र के क्रैश होने, Content-Security-Policy के उल्लंघनों, COOP/COEP के उल्लंघनों, बंद होने की चेतावनियों वगैरह के बारे में जानकारी मिलती है.

Reporting API का नया वर्शन उपलब्ध है. नया एपीआई, कम डेटा का इस्तेमाल करता है. साथ ही, इसकी ज़्यादा संभावना है कि यह सभी ब्राउज़र पर काम करे.

खास जानकारी

साइट डेवलपर

अगर आपकी साइट के लिए पहले से ही रिपोर्टिंग की सुविधा मौजूद है, तो नए हेडर (Reporting-Endpoints) का इस्तेमाल करके, v1 पर माइग्रेट करें. हालांकि, लेगसी हेडर को कुछ समय के लिए बनाए रखें (Report-To). माइग्रेशन: कोड का उदाहरण देखें.

अगर आपको अभी अपनी साइट में रिपोर्टिंग की सुविधा जोड़नी है, तो सिर्फ़ नए हेडर (Reporting-Endpoints) का इस्तेमाल करें.

⚠️ दोनों ही मामलों में, उन सभी रिस्पॉन्स पर Reporting-Endpoints हेडर सेट करना न भूलें जिनसे रिपोर्ट जनरेट हो सकती हैं.

रिपोर्टिंग सेवा के डेवलपर

अगर आपके पास एंडपॉइंट सेवा मैनेज करने या अपनी सेवा चलाने की ज़िम्मेदारी है, तो आपको ज़्यादा ट्रैफ़िक मिल सकता है. ऐसा इसलिए, क्योंकि आप या बाहरी डेवलपर, Reporting API v1 (Reporting-Endpoints हेडर) पर माइग्रेट कर रहे हैं.

ज़्यादा जानकारी और कोड के उदाहरण के लिए, पढ़ना जारी रखें!

नेटवर्क की गड़बड़ी की लॉगिंग

नेटवर्क से जुड़ी गड़बड़ी को लॉग करने के लिए, एक नया तरीका विकसित किया जाएगा. यह सुविधा उपलब्ध होने के बाद, Reporting API के वर्शन 0 से नए तरीके पर स्विच करें.

डेमो और कोड

v0 और v1 के बीच अंतर

क्या बदल रहा है

  • एपीआई का प्लैटफ़ॉर्म अलग है.
v0 (लेगसी)
 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 डायरेक्टिव का इस्तेमाल करता है.

v1 (नया)
 Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
 Document-Policy: ...; report-to main-endpoint

v1, named endpoints को कॉन्फ़िगर करने के लिए Reporting-Endpoints हेडर का इस्तेमाल करता है. v0 की तरह, यह इन एंडपॉइंट ग्रुप का रेफ़रंस देने के लिए, दूसरे हेडर में report-to डायरेक्टिव का इस्तेमाल करता है.

  • रिपोर्ट का दायरा अलग है.
v0 (लेगसी)

v0 में, सिर्फ़ कुछ जवाबों के लिए रिपोर्टिंग एंडपॉइंट सेट किए जा सकते हैं. उस ऑरिजिन के अन्य दस्तावेज़ (पेज), इन ऐंबियंट एंडपॉइंट का अपने-आप इस्तेमाल करेंगे.

v1 (नया)

v1 के साथ, आपको उन सभी रिस्पॉन्स पर Reporting-Endpoints हेडर सेट करना होगा जिनसे रिपोर्ट जनरेट हो सकती हैं.

  • दोनों एपीआई, एक ही तरह की रिपोर्ट के साथ काम करते हैं. हालांकि, v1 में नेटवर्क से जुड़ी गड़बड़ी की रिपोर्ट काम नहीं करती हैं. ज़्यादा जानकारी के लिए, डेटा को दूसरी जगह भेजने के तरीके लेख पढ़ें.
  • v0 वर्शन, सभी ब्राउज़र पर काम नहीं करता और आने वाले समय में भी नहीं करेगा. हालांकि, आने वाले समय में v1 वर्शन, कई ब्राउज़र पर काम कर सकता है.

क्या नहीं बदला

  • रिपोर्ट के फ़ॉर्मैट और स्ट्रक्चर में कोई बदलाव नहीं हुआ है.
  • ब्राउज़र से एंडपॉइंट पर भेजा गया अनुरोध, Content-type के लिए POST का अनुरोध बना रहता है application/reports+json.
  • कुछ खास एंडपॉइंट को कुछ खास रिपोर्ट टाइप से मैप करने की सुविधा, v0 और v1, दोनों में काम करती है.
  • default एंडपॉइंट की भूमिका में कोई बदलाव नहीं हुआ है.

  • Reporting API के वर्शन 1 का ReportingObserver पर कोई असर नहीं पड़ेगा. ReportingObserver को अब भी उन सभी रिपोर्ट का ऐक्सेस मिलता रहेगा जिन्हें निगरानी की जा सकती है. साथ ही, इन रिपोर्ट का फ़ॉर्मैट भी एक जैसा रहेगा.

v0 और v1 के बीच के सभी अंतर

लेगसी Reporting API (v0)
Report-To हेडर		 नया Reporting API (v1)
Reporting-Endpoints हेडर
ब्राउज़र समर्थन Chrome 69 और इसके बाद के वर्शन और Edge 69 और इसके बाद के वर्शन. Chrome 96 और इसके बाद के वर्शन और Edge 96 और इसके बाद के वर्शन. Firefox पर भी यह सुविधा काम करती है. Safari कोई विरोध नहीं करता. ब्राउज़र सिग्नल देखें.
एंडपॉइंट रिपोर्ट को एक से ज़्यादा रिपोर्ट कलेक्टर (हर एंडपॉइंट ग्रुप के लिए तय किए गए कई यूआरएल) में से किसी एक को भेजता है. रिपोर्ट को खास रिपोर्ट कलेक्टर को भेजता है. हर एंडपॉइंट के लिए सिर्फ़ एक यूआरएल तय किया जाता है.
एपीआई का प्लैटफ़ॉर्म नाम वाले एंडपॉइंट ग्रुप को कॉन्फ़िगर करने के लिए, `Report-To` हेडर का इस्तेमाल करता है. नाम वाले एंडपॉइंट को कॉन्फ़िगर करने के लिए, `Reporting-Endpoints` हेडर का इस्तेमाल करता है.
इस एपीआई की मदद से जनरेट की जा सकने वाली रिपोर्ट के टाइप
  • बंद होना
  • इंटरवेंशन
  • क्रैश
  • COOP/COEP
  • Content-Security-Policy लेवल 3 (सीएसपी लेवल 3)
  • नेटवर्क गड़बड़ी की जानकारी देने वाली लॉगिंग (एनईएल)
Reporting API पोस्ट में, रिपोर्ट के टाइप के बारे में ज़्यादा जानें. 		नेटवर्क गड़बड़ी लॉगिंग (एनईएल): यह Reporting API के नए वर्शन (v1) में काम नहीं करता को छोड़कर, इसमें कोई बदलाव नहीं किया गया है.
रिपोर्ट का दायरा मूल दस्तावेज़ के तौर पर दिखाता है.
किसी दस्तावेज़ के Report-To हेडर से, उस ऑरिजिन के दूसरे दस्तावेज़ों (पेजों) पर असर पड़ता है. हालांकि, रिपोर्ट का url फ़ील्ड अब भी हर दस्तावेज़ के हिसाब से अलग-अलग होता है. 		दस्तावेज़.
किसी दस्तावेज़ के Reporting-Endpoints हेडर का असर सिर्फ़ उस दस्तावेज़ पर पड़ता है. हालांकि, रिपोर्ट का url फ़ील्ड अब भी हर दस्तावेज़ के हिसाब से अलग-अलग होता है.
रिपोर्ट को अलग-अलग करना (बैच में भेजना) एक ही समय पर रिपोर्ट जनरेट करने वाले और एक ही रिपोर्टिंग एंडपॉइंट वाले अलग-अलग दस्तावेज़ (पेज) या साइटों/ऑरिजिन को एक साथ भेजा जाएगा: उन्हें रिपोर्टिंग एंडपॉइंट पर एक ही मैसेज में भेजा जाएगा.
  • अलग-अलग दस्तावेज़ों (पेजों) की रिपोर्ट कभी एक साथ नहीं भेजी जातीं. भले ही, एक ही ऑरिजिन के दो दस्तावेज़ (पेज) एक ही समय पर एक ही एंडपॉइंट के लिए रिपोर्ट जनरेट करें, लेकिन इन्हें एक साथ नहीं भेजा जाएगा. यह निजता से जुड़े हमलों को कम करने का एक तरीका है.
  • एक ही दस्तावेज़ (पेज) की रिपोर्ट एक साथ भेजी जा सकती हैं.
लोड बैलेंसिंग / प्राथमिकताओं के लिए सहायता हां नहीं

एंडपॉइंट डेवलपर: ज़्यादा ट्रैफ़िक की उम्मीद करें

अगर आपने रिपोर्टिंग एंडपॉइंट के तौर पर अपना सर्वर सेट अप किया है या सेवा के तौर पर रिपोर्ट कलेक्टर को डेवलप या मैनेज किया जा रहा है, तो उस एंडपॉइंट पर ज़्यादा ट्रैफ़िक आने की उम्मीद करें.

इसकी वजह यह है कि Reporting API के वर्शन 1 में, रिपोर्ट को Reporting API के वर्शन 0 की तरह एक साथ नहीं भेजा जाता. इसलिए, ऐप्लिकेशन डेवलपर के Reporting API v1 पर माइग्रेट करने के बाद, रिपोर्ट की संख्या पहले जैसी ही रहेगी. हालांकि, एंडपॉइंट सर्वर पर अनुरोधों की संख्या बढ़ जाएगी.

ऐप्लिकेशन डेवलपर: Reporting-Endpoints (v1) पर माइग्रेट करना

ऐसे में आपको क्या करना चाहिए?

Reporting API के नए वर्शन (v1) का इस्तेमाल करने के कई फ़ायदे हैं ✅:

  • ब्राउज़र सिग्नल पॉज़िटिव हैं. इसका मतलब है कि वर्शन 1 के लिए, अलग-अलग ब्राउज़र पर काम करने की सुविधा मिल सकती है. यह सुविधा वर्शन 0 के लिए नहीं मिलती, जो सिर्फ़ Chrome और Edge पर काम करता है.
  • एपीआई का साइज़ कम है.
  • टूल, Reporting API के नए वर्शन (v1) के हिसाब से डेवलप किए जा रहे हैं.

इन बातों को ध्यान में रखकर:

  • अगर आपकी साइट पहले से ही Report-To हेडर के साथ Reporting API v0 का इस्तेमाल करती है, तो Reporting API v1 पर माइग्रेट करें (डेटा को दूसरी जगह भेजने का तरीका देखें). अगर आपकी साइट पर पहले से ही, कॉन्टेंट की सुरक्षा के बारे में नीति के उल्लंघनों की शिकायत करने की सुविधा का इस्तेमाल किया जा रहा है, तो सीएसपी रिपोर्टिंग के लिए माइग्रेशन के खास चरणों को देखें.
  • अगर आपकी साइट पर पहले से ही Reporting API का इस्तेमाल नहीं किया जा रहा है और अब आपको रिपोर्टिंग की सुविधा जोड़नी है, तो: Reporting API के नए वर्शन (v1) (Reporting-Endpoints हेडर) का इस्तेमाल करें. इसमें एक अपवाद है: अगर आपको नेटवर्क गड़बड़ी को लॉग करने की सुविधा का इस्तेमाल करना है, तो Report-To (v0) का इस्तेमाल करें. फ़िलहाल, Reporting API v1 में नेटवर्क गड़बड़ी की जानकारी को लॉग करने की सुविधा काम नहीं करती. नेटवर्क से जुड़ी गड़बड़ी को लॉग करने के लिए, एक नया तरीका विकसित किया जाएगा⏤जब तक यह उपलब्ध नहीं हो जाता, तब तक Reporting API के वर्शन 0 का इस्तेमाल करें. अगर आपको अन्य तरह की रिपोर्ट के साथ-साथ नेटवर्क गड़बड़ी की जानकारी देने वाली लॉगिंग की ज़रूरत है, तो Report-To (v0) और Reporting-Endpoints (v1), दोनों का इस्तेमाल करें. v0 से आपको नेटवर्क गड़बड़ी की जानकारी देने वाली लॉगिंग मिलती है और v1 से आपको अन्य सभी तरह की रिपोर्ट मिलती हैं.

माइग्रेट करने का तरीका

इस माइग्रेशन का मकसद, v0 में मिलने वाली रिपोर्ट को न खोना है.

  1. पहला चरण (अभी करें): दोनों हेडर का इस्तेमाल करें: Report-To (v0) और Reporting-Endpoints (v1).

    इससे आपको ये फ़ायदे मिलते हैं:

    • Reporting-Endpoints (v1) की मदद से, नए Chrome और Edge क्लाइंट से मिलने वाली रिपोर्ट.
    • Report-To (v0) की मदद से, पुराने Chrome और Edge क्लाइंट से मिली रिपोर्ट.

    Reporting-Endpoints के साथ काम करने वाले ब्राउज़र इंस्टेंस, Reporting-Endpoints का इस्तेमाल करेंगे. वहीं, जिन इंस्टेंस में यह सुविधा काम नहीं करती वे Report-To पर फ़ॉलबैक करेंगे. अनुरोध और रिपोर्ट का फ़ॉर्मैट, v0 और v1 के लिए एक जैसा है.

  2. दूसरा चरण (अभी करें): पक्का करें कि उन सभी रिस्पॉन्स पर Reporting-Endpoints हेडर सेट हो जिनसे रिपोर्ट जनरेट हो सकती हैं.

    v0 में, सिर्फ़ कुछ जवाबों पर रिपोर्टिंग एंडपॉइंट सेट करने का विकल्प चुना जा सकता है. साथ ही, उस ऑरिजिन के अन्य दस्तावेज़ (पेज), इस "ऐंबियंट" एंडपॉइंट का इस्तेमाल करेंगे. v1 में, स्कोपिंग में अंतर की वजह से, आपको उन सभी रिस्पॉन्स पर Reporting-Endpoints हेडर सेट करना होगा जिनसे रिपोर्ट जनरेट हो सकती हैं.

  3. तीसरा चरण (बाद में शुरू करें): जब आपके सभी या ज़्यादातर उपयोगकर्ता, Chrome या Edge के नए वर्शन (96 और उसके बाद के वर्शन) पर अपडेट हो जाएं, तो Report-To (v0) को हटा दें और सिर्फ़ Reporting-Endpoints को रखें.

    एक अपवाद: अगर आपको नेटवर्क गड़बड़ी की लॉगिंग रिपोर्ट की ज़रूरत है, तो नेटवर्क गड़बड़ी की लॉगिंग के लिए नया तरीका लागू होने तक Report-To को सेट करें.

माइग्रेशन कुकबुक में कोड के उदाहरण देखें.

सीएसपी रिपोर्टिंग के लिए माइग्रेशन का तरीका

Content-Security-Policy के उल्लंघन की रिपोर्ट को कॉन्फ़िगर करने के दो तरीके हैं:

  • report-uri डायरेक्टिव की मदद से, सिर्फ़ CSP हेडर के साथ. यह सुविधा Chrome, Firefox, Safari, और Edge जैसे कई ब्राउज़र पर काम करती है. रिपोर्ट, कॉन्टेंट-टाइप application/csp-report के साथ भेजी जाती हैं और उनका फ़ॉर्मैट, सीएसपी के हिसाब से होता है. इन रिपोर्ट को "सीएसपी लेवल 2 रिपोर्ट" कहा जाता है. ये रिपोर्ट, Reporting API पर नहीं निर्भर करती हैं.
  • Reporting API की मदद से, Report-To हेडर (लेगसी) या नए Reporting-Endpoints (v1) के ज़रिए. यह सुविधा सिर्फ़ Chrome और Edge पर काम करती है. रिपोर्ट के अनुरोधों का फ़ॉर्मैट, Reporting API के अन्य अनुरोधों जैसा ही होता है. साथ ही, इनका कॉन्टेंट टाइप भी application/reports+json होता है.

पहले तरीके (सिर्फ़ report-uri) का इस्तेमाल करने का अब सुझाव नहीं दिया जाता. वहीं, दूसरे तरीके का इस्तेमाल करने के कुछ फ़ायदे हैं. खास तौर पर, इसकी मदद से सभी तरह की रिपोर्ट के लिए रिपोर्टिंग सेट अप करने के साथ-साथ, एक सामान्य एंडपॉइंट भी सेट अप किया जा सकता है. इसकी वजह यह है कि Reporting API⏤CSP और अन्य⏤ के ज़रिए जनरेट किए गए सभी रिपोर्ट अनुरोधों का फ़ॉर्मैट एक ही होता है application/reports+json.

हालांकि, सिर्फ़ कुछ ब्राउज़र पर report-to काम करता है. इसलिए, हमारा सुझाव है कि आप कई ब्राउज़र से सीएसपी के उल्लंघन की रिपोर्ट पाने के लिए, Reporting API के तरीके (Report-To या बेहतर तरीके से, Reporting-Endpoints) के साथ-साथ report-uri का इस्तेमाल करें. report-uri और report-to को पहचानने वाले ब्राउज़र में, report-to मौजूद होने पर report-uri को अनदेखा कर दिया जाएगा. अगर किसी ब्राउज़र में सिर्फ़ report-uri को पहचाना जाता है, तो सिर्फ़ report-uri को ही स्वीकार किया जाएगा.

  1. पहला चरण (अभी करें): अगर आपने अब तक report-uri के साथ report-to नहीं जोड़ा है, तो उसे जोड़ें. सिर्फ़ report-uri (Firefox) के साथ काम करने वाले ब्राउज़र, report-uri का इस्तेमाल करेंगे. वहीं, report-to(Chrome, Edge) के साथ काम करने वाले ब्राउज़र, report-to का इस्तेमाल करेंगे. report-to में इस्तेमाल किए जाने वाले नाम वाले एंडपॉइंट की जानकारी देने के लिए, हेडर Report-To और Reporting-Endpoints, दोनों का इस्तेमाल करें. इससे यह पक्का होता है कि आपको Chrome और Edge के पुराने और नए, दोनों क्लाइंट से रिपोर्ट मिलती हैं.

  2. तीसरा चरण (बाद में शुरू करें): जब आपके सभी या ज़्यादातर उपयोगकर्ता, Chrome या Edge के नए वर्शन (96 और उसके बाद के वर्शन) पर अपडेट हो जाएं, तो Report-To (v0) को हटा दें और सिर्फ़ Reporting-Endpoints को रखें. report-uri को चालू रखें, ताकि आपको अब भी उन ब्राउज़र के लिए रिपोर्ट मिलती रहें जो सिर्फ़ इस सुविधा के साथ काम करते हैं.

सीएसपी रिपोर्टिंग माइग्रेशन में, इन चरणों के लिए कोड के उदाहरण देखें.

माइग्रेशन: कोड का उदाहरण

खास जानकारी

अगर आपने सीओओपी (Cross-Origin-Opener-Policy हेडर), सीओईपी (Cross-Origin-Embedder-Policy) या दस्तावेज़ नीति (Document-Policy हेडर) के उल्लंघन की रिपोर्ट पाने के लिए, Reporting API के लेगसी वर्शन (v0) का इस्तेमाल किया है, तो आपको Reporting API के वर्शन 1 पर माइग्रेट करते समय, इन नीति हेडर को खुद बदलने की ज़रूरत नहीं है. आपको लेगसी Report-To हेडर से नए Reporting-Endpoints हेडर पर माइग्रेट करना होगा.

अगर किसी सीएसपी (Content-Security-Policy हेडर) के लिए, नीति के उल्लंघन की रिपोर्ट पाने के लिए, Reporting API के लेगसी वर्शन (v0) का इस्तेमाल किया जा रहा है, तो आपको Reporting API के नए वर्शन (v1) पर माइग्रेट करने के लिए, अपने Content-Security-Policy में बदलाव करना पड़ सकता है.

बुनियादी माइग्रेशन

लेगसी कोड (v0 के साथ)
Report-To: { group: "main-endpoint", "endpoints": [ { "url": "https://reports.example/main" }] }, { group: "default-endpoint", "endpoints": [ { "url": "https://reports.example/default" }] }
नया कोड (v1 के साथ-साथ v0 वाला ट्रांज़िशन कोड)
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 को तब तक चालू रखें, जब तक नेटवर्क लॉगिंग की सुविधा का विकल्प उपलब्ध नहीं हो जाता.

नया कोड (सिर्फ़ v1 के साथ)
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

आने वाले समय में, Chrome और Edge के ज़्यादातर क्लाइंट अपडेट हो जाने और एपीआई v1 के साथ काम करने के बाद, आपका कोड ऐसा दिख सकता है.

ध्यान दें कि v1 में, अब भी खास एंडपॉइंट पर खास रिपोर्ट टाइप भेजे जा सकते हैं. हालांकि, हर एंडपॉइंट के लिए सिर्फ़ एक यूआरएल हो सकता है.

सभी पेजों को देखना

लेगसी कोड (v0 के साथ), जैसे कि एक्सप्रेस के साथ
app.get("/", (request, response) => {
  response.set("Report-To", …)
  response.render(...)
});
app.get("/page1", (request, response) => {
  response.render(...)
});

v0 में, सिर्फ़ कुछ जवाबों के लिए रिपोर्टिंग एंडपॉइंट सेट किए जा सकते हैं. उस ऑरिजिन के अन्य दस्तावेज़ (पेज), इन ऐंबियंट एंडपॉइंट का अपने-आप इस्तेमाल करते हैं. यहां, "/" के लिए सेट किए गए एंडपॉइंट का इस्तेमाल सभी रिस्पॉन्स के लिए किया जाता है. उदाहरण के लिए, page1 के लिए.

नया कोड (v1 के साथ), जैसे कि Express के साथ
// 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 हेडर सेट करना होगा जिनसे रिपोर्ट जनरेट हो सकती हैं.

सीएसपी रिपोर्टिंग माइग्रेशन

सिर्फ़ report-uri वाला लेगसी कोड
Content-Security-Policy: ...; report-uri https://reports.example/main

report-uri का इस्तेमाल करने का सुझाव अब नहीं दिया जाता. अगर आपका कोड ऊपर दिए गए कोड जैसा दिखता है, तो माइग्रेट करें. नीचे दिए गए नए कोड के उदाहरण देखें (हरे रंग में).

बेहतर लेगसी कोड, जिसमें report-uri और report-to डायरेक्टिव के साथ Report-To (v0) हेडर है
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 पर माइग्रेट करें: नीचे दिए गए 'नया कोड' के उदाहरण (हरे रंग में) देखें.

नया कोड, जिसमें report-uri और report-to डायरेक्टिव के साथ Reporting-Endpoints (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-to डायरेक्टिव के साथ report-uri डायरेक्टिव तब तक इस्तेमाल करें, जब तक report-to डायरेक्टिव सभी ब्राउज़र पर काम नहीं करने लगता. अलग-अलग ब्राउज़र पर साइट की जांच करने के लिए बनी टेबल देखें.

Report-To को कुछ समय के लिए Reporting-Endpoints के साथ रखें. जब आपके Chrome और Edge का इस्तेमाल करने वाले ज़्यादातर लोग, ब्राउज़र के 96 और उसके बाद के वर्शन पर अपग्रेड कर लें, तब Report-To को हटा दें.

इसके बारे में और पढ़ें

इस लेख पर अपनी समीक्षाएं और सुझाव देने के लिए, इयान क्लेलैंड, एइजी कितामुरा, और मिलिका मिहाइलिया का बहुत-बहुत धन्यवाद.