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

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

Maud Nalpas

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 v0 से नए मेकेनिज़्म पर स्विच करें.

डेमो और कोड

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, नाम वाले एंडपॉइंट को कॉन्फ़िगर करने के लिए, Reporting-Endpoints हेडर का इस्तेमाल करता है. v0 की तरह, यह भी इन एंडपॉइंट ग्रुप का रेफ़रंस देने के लिए, अन्य हेडर में report-to डायरेक्टिव का इस्तेमाल करता है.

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

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

v1 (नई सुविधा)

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

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

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

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

  • Reporting API v1 का 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 Level 3 (CSP Level 3)
  • नेटवर्क की गड़बड़ी लॉग करने की सुविधा (एनईएल)
Reporting API पोस्ट में रिपोर्ट के टाइप के बारे में ज़्यादा जानें. 		इसमें कोई बदलाव नहीं किया गया है. हालांकि, नेटवर्क की गड़बड़ी के लॉग (एनईएल): यह नए 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 पर काम करता है.
  • यह एपीआई कम संसाधनों का इस्तेमाल करता है.
  • नए Reporting API (v1) के लिए टूल डेवलप किए जा रहे हैं.

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

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

  • सिर्फ़ CSP हेडर के साथ, report-uri डायरेक्टिव के ज़रिए. यह सुविधा Chrome, Firefox, Safari, और Edge जैसे कई ब्राउज़र पर काम करती है. रिपोर्ट, कॉन्टेंट-टाइप application/csp-report के साथ भेजी जाती हैं. इनका फ़ॉर्मैट, CSP के हिसाब से तय होता है. इन रिपोर्ट को "CSP Level 2 Reports" कहा जाता है. ये 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 काम करता है. इसलिए, हमारा सुझाव है कि आप रिपोर्टिंग एपीआई के साथ-साथ report-uri का इस्तेमाल करें. Report-To या बेहतर तरीके से Reporting-Endpoints का इस्तेमाल करके, अलग-अलग ब्राउज़र से सीएसपी उल्लंघन की रिपोर्ट पाएं. 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 v1 पर माइग्रेट करते समय, आपको इन नीति हेडर को बदलने की ज़रूरत नहीं है. आपको लेगसी 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" }] }
नया कोड (v0 के साथ v1 वाला ट्रांज़िशन कोड)
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 के साथ), उदाहरण के लिए Express के साथ
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 हेडर सेट करना होगा जिनसे रिपोर्ट जनरेट हो सकती हैं.

CSP रिपोर्टिंग माइग्रेशन

लेगसी कोड, जिसमें सिर्फ़ report-uri मौजूद है
Content-Security-Policy: ...; report-uri https://reports.example/main

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

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

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

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

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