Reporting API की मदद से अपने वेब ऐप्लिकेशन की निगरानी करना

Reporting API का इस्तेमाल करके, सुरक्षा से जुड़े उल्लंघनों, अब काम न करने वाले एपीआई कॉल वगैरह पर नज़र रखें.

Maud Nalpas

कुछ गड़बड़ियां सिर्फ़ प्रोडक्शन में होती हैं. आपको ये समस्याएं स्थानीय तौर पर या डेवलपमेंट के दौरान नहीं दिखेंगी. इसकी वजह यह है कि असल उपयोगकर्ता, असल नेटवर्क, और असल डिवाइस, गेम को बदल देते हैं. Reporting API, इनमें से कुछ गड़बड़ियों का पता लगाने में मदद करता है. जैसे, सुरक्षा से जुड़े उल्लंघन या आपकी साइट पर मौजूद ऐसे एपीआई कॉल जो अब काम नहीं करते और जल्द ही काम करना बंद कर देंगे. साथ ही, यह उन्हें आपके बताए गए एंडपॉइंट पर भेजता है.

इसकी मदद से, यह तय किया जा सकता है कि आपको एचटीटीपी हेडर का इस्तेमाल करके क्या मॉनिटर करना है. इसे ब्राउज़र से ऑपरेट किया जाता है.

Reporting API सेट अप करने से आपको यह भरोसा मिलता है कि जब उपयोगकर्ताओं को इस तरह की गड़बड़ियों का सामना करना पड़ेगा, तो आपको इसकी जानकारी मिल जाएगी. इससे आपको उन्हें ठीक करने में मदद मिलेगी.

इस पोस्ट में बताया गया है कि इस एपीआई का इस्तेमाल करके क्या-क्या किया जा सकता है और इसे कैसे इस्तेमाल किया जा सकता है. चलिए, शुरू करते हैं!

खास जानकारी

मान लें कि आपकी साइट site.example में, कॉन्टेंट की सुरक्षा के लिए नीति और दस्तावेज़ की नीति मौजूद है. क्या आपको नहीं पता कि ये क्या काम करते हैं? कोई बात नहीं, इस उदाहरण को अब भी समझा जा सकता है.

अपनी साइट पर नज़र रखने का फ़ैसला लिया जा सकता है, ताकि यह पता चल सके कि इन नीतियों का उल्लंघन कब हुआ. इसके अलावा, ऐसा इसलिए भी किया जा सकता है, ताकि उन एपीआई पर नज़र रखी जा सके जो अब काम नहीं करते या जल्द ही काम करना बंद कर देंगे. ऐसा हो सकता है कि आपका कोड बेस इन एपीआई का इस्तेमाल कर रहा हो.

इसके लिए, Reporting-Endpoints हेडर कॉन्फ़िगर करें. साथ ही, अपनी नीतियों में जहां ज़रूरी हो वहां report-to डायरेक्टिव का इस्तेमाल करके, इन एंडपॉइंट के नामों को मैप करें.

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

कोई ऐसी गड़बड़ी हो जाए जिसकी उम्मीद न हो और आपके कुछ उपयोगकर्ताओं के लिए इन नीतियों का उल्लंघन हो जाए.

उल्लंघनों के उदाहरण

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js, index.html ने लोड किया

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

ब्राउज़र, सीएसपी के उल्लंघन की रिपोर्ट, दस्तावेज़-नीति के उल्लंघन की रिपोर्ट, और बंद होने की रिपोर्ट जनरेट करता है. इनमें इन समस्याओं को कैप्चर किया जाता है.

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

एंडपॉइंट को ये रिपोर्ट मिलती हैं.

अब इन एंडपॉइंट पर रिपोर्ट ऐक्सेस की जा सकती हैं और यह मॉनिटर किया जा सकता है कि क्या गड़बड़ी हुई. अब आपके उपयोगकर्ताओं पर असर डालने वाली समस्या को हल किया जा सकता है.

उदाहरण के तौर पर दी गई रिपोर्ट

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://site.example",
  "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}

इस्तेमाल के उदाहरण और रिपोर्ट के टाइप

Reporting API को कॉन्फ़िगर करके, अपनी साइट पर होने वाली कई तरह की दिलचस्प चेतावनियों या समस्याओं पर नज़र रखी जा सकती है:

रिपोर्ट

ब्राउज़र, रिपोर्ट को उस एंडपॉइंट पर भेजता है जिसे आपने कॉन्फ़िगर किया है. यह इस तरह के अनुरोध भेजता है:

POST
Content-Type: application/reports+json

इन अनुरोधों के पेलोड में रिपोर्ट की सूची होती है.

रिपोर्ट की उदाहरण सूची

[
  {
    "age": 420,
    "body": {
      "columnNumber": 12,
      "disposition": "enforce",
      "lineNumber": 11,
      "message": "Document policy violation: document-write is not allowed in this document.",
      "policyId": "document-write",
      "sourceFile": "https://site.example/script.js"
    },
    "type": "document-policy-violation",
    "url": "https://site.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  },
  {
    "age": 510,
    "body": {
      "blockedURL": "https://site.example/img.jpg",
      "destination": "image",
      "disposition": "enforce",
      "type": "corp"
    },
    "type": "coep",
    "url": "https://dummy.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  }
]

यहां बताया गया है कि आपको इनमें से हर रिपोर्ट में कौनसा डेटा मिलेगा:

क्रेडेंशियल वाली रिपोर्ट

रिपोर्ट जनरेट करने वाले पेज के समान ऑरिजिन वाले रिपोर्टिंग एंडपॉइंट को, रिपोर्ट वाले अनुरोधों में क्रेडेंशियल (कुकी) मिलते हैं.

क्रेडेंशियल से, रिपोर्ट के बारे में काम की अतिरिक्त जानकारी मिल सकती है. उदाहरण के लिए, क्या किसी उपयोगकर्ता के खाते से लगातार गड़बड़ियां ट्रिगर हो रही हैं या अन्य पेजों पर की गई कार्रवाइयों के किसी खास क्रम की वजह से, इस पेज पर कोई रिपोर्ट ट्रिगर हो रही है.

ब्राउज़र, रिपोर्ट कब और कैसे भेजता है?

रिपोर्ट आपकी साइट से आउट-ऑफ़-बैंड डिलीवर की जाती हैं: ब्राउज़र यह कंट्रोल करता है कि उन्हें कॉन्फ़िगर किए गए एंडपॉइंट पर कब भेजा जाए. ब्राउज़र कब रिपोर्ट भेजेगा, इसे कंट्रोल करने का भी कोई तरीका नहीं है. यह रिपोर्ट को कैप्चर करता है, सूची में जोड़ता है, और सही समय पर अपने-आप भेज देता है.

इसका मतलब है कि Reporting API का इस्तेमाल करने पर, परफ़ॉर्मेंस से जुड़ी कोई समस्या नहीं होती.

रिपोर्ट को देरी से भेजा जाता है—एक मिनट तक—ताकि रिपोर्ट को बैच में भेजने की संभावना बढ़ाई जा सके. इससे बैंडविड्थ सेव होता है, ताकि उपयोगकर्ता के इंटरनेट कनेक्शन पर असर न पड़े. यह खास तौर पर मोबाइल पर ज़रूरी होता है. अगर ब्राउज़र ज़्यादा प्राथमिकता वाले काम को प्रोसेस करने में व्यस्त है, तो वह सूचनाएं भेजने में देरी कर सकता है. इसके अलावा, अगर उपयोगकर्ता उस समय धीमे या व्यस्त नेटवर्क पर है, तो भी सूचनाएं भेजने में देरी हो सकती है.

तीसरे और पहले पक्ष की समस्याएं

नीतियों के उल्लंघन या आपके पेज पर होने वाले बदलावों की वजह से जनरेट हुई रिपोर्ट, उन एंडपॉइंट पर भेजी जाएंगी जिन्हें आपने कॉन्फ़िगर किया है. इसमें आपके पेज पर मौजूद तीसरे पक्ष की स्क्रिप्ट से होने वाले उल्लंघन भी शामिल हैं.

आपके पेज में एम्बेड किए गए क्रॉस-ऑरिजिन iframe में हुए उल्लंघनों या डेप्रिकेशन की जानकारी, आपके एंडपॉइंट को नहीं दी जाएगी. कम से कम डिफ़ॉल्ट रूप से ऐसा नहीं होगा. कोई iframe अपनी रिपोर्टिंग सेट अप कर सकता है. साथ ही, आपकी साइट की रिपोर्टिंग सेवा को भी रिपोर्ट कर सकता है. हालांकि, यह फ़्रेम की गई साइट पर निर्भर करता है. यह भी ध्यान दें कि ज़्यादातर रिपोर्ट तब जनरेट होती हैं, जब किसी पेज की नीति का उल्लंघन होता है. साथ ही, आपके पेज की नीतियां और iframe की नीतियां अलग-अलग होती हैं.

बंद की गई सुविधाओं के साथ उदाहरण

ब्राउज़र समर्थन

नीचे दी गई टेबल में, Reporting API v1 के लिए ब्राउज़र से मिलने वाली सहायता के बारे में बताया गया है. यह सहायता, Reporting-Endpoints हेडर के साथ मिलती है. Reporting API v0 (Report-To हेडर) के लिए ब्राउज़र सपोर्ट एक जैसा है. हालांकि, एक रिपोर्ट टाइप के लिए ऐसा नहीं है: नेटवर्क की गड़बड़ी लॉगिंग, नए Reporting API में काम नहीं करती. ज़्यादा जानकारी के लिए, माइग्रेट करने से जुड़ी गाइड पढ़ें.

इस टेबल में, सिर्फ़ नए Reporting-Endpoints हेडर के साथ report-to के काम करने की जानकारी दी गई है. अगर आपको Reporting-Endpoints पर माइग्रेट करना है, तो सीएसपी रिपोर्टिंग माइग्रेशन से जुड़ी सलाह पढ़ें.

Reporting API का इस्तेमाल करना

तय करें कि रिपोर्ट कहां भेजी जानी चाहिए

आपके पास दो विकल्प हैं:

• रिपोर्ट को किसी मौजूदा रिपोर्ट कलेक्टर सेवा पर भेजना.
• रिपोर्टिंग कलेक्टर को रिपोर्ट भेजें. इसे आपको खुद बनाना और मैनेज करना होता है.

पहला विकल्प: रिपोर्ट इकट्ठा करने वाली किसी मौजूदा सेवा का इस्तेमाल करना

रिपोर्ट इकट्ठा करने वाली सेवाओं के कुछ उदाहरण यहां दिए गए हैं:

• report-uri
• uriports
• HeaderHawk
• Sentry

अगर आपको कोई और तरीका पता है, तो हमें बताने के लिए समस्या की जानकारी दें. इसके बाद, हम इस पोस्ट को अपडेट कर देंगे!

रिपोर्ट कलेक्टर चुनते समय, शुल्क के अलावा इन बातों का भी ध्यान रखें: 🧐

• क्या यह कलेक्टर, सभी तरह की रिपोर्ट के साथ काम करता है? उदाहरण के लिए, सभी रिपोर्टिंग एंडपॉइंट सॉल्यूशन, COOP/COEP रिपोर्ट के साथ काम नहीं करते.
• क्या आपको अपने ऐप्लिकेशन के किसी भी यूआरएल को तीसरे पक्ष के रिपोर्ट कलेक्टर के साथ शेयर करने में कोई परेशानी है? भले ही, ब्राउज़र इन यूआरएल से संवेदनशील जानकारी हटा देता है, लेकिन इस तरह से संवेदनशील जानकारी लीक हो सकती है. अगर आपको लगता है कि यह आपके ऐप्लिकेशन के लिए बहुत जोखिम भरा है, तो रिपोर्टिंग एंडपॉइंट को खुद मैनेज करें.

दूसरा विकल्प: खुद का रिपोर्ट कलेक्टर बनाना और उसे मैनेज करना

रिपोर्ट पाने के लिए, अपना सर्वर बनाना आसान नहीं है. शुरू करने के लिए, हमारे लाइटवेट बॉयलरप्लेट को फ़ोर्क किया जा सकता है. इसे Express की मदद से बनाया गया है. यह रिपोर्ट पा सकता है और दिखा सकता है.

खुद का रिपोर्ट कलेक्टर बनाने पर:

• application/reports+json के साथ Content-Type वाले POST अनुरोधों की जांच करें, ताकि ब्राउज़र से आपके एंडपॉइंट पर भेजे गए रिपोर्ट के अनुरोधों का पता लगाया जा सके.
• अगर आपका एंडपॉइंट, आपकी साइट से अलग ऑरिजिन पर मौजूद है, तो पक्का करें कि वह सीओआरएस प्रीफ़्लाइट अनुरोधों के साथ काम करता हो.

तीसरा विकल्प: पहले और दूसरे विकल्प को एक साथ इस्तेमाल करना

ऐसा हो सकता है कि आपको किसी खास सेवा देने वाली कंपनी को कुछ तरह की रिपोर्ट मैनेज करने की अनुमति देनी हो, लेकिन अन्य रिपोर्ट के लिए आपके पास इन-हाउस समाधान हो.

इस मामले में, एक से ज़्यादा एंडपॉइंट इस तरह सेट करें:

Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"

Reporting-Endpoints हेडर को कॉन्फ़िगर करना

Reporting-Endpoints रिस्पॉन्स हेडर सेट करें. इसकी वैल्यू, कॉमा लगाकर अलग किए गए की-वैल्यू पेयर की एक या उससे ज़्यादा सीरीज़ होनी चाहिए:

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

अगर आपको लेगसी Reporting API से नए Reporting API पर माइग्रेट करना है, तो दोनों Reporting-Endpoints और Report-To को सेट करना सही हो सकता है. ज़्यादा जानकारी के लिए, माइग्रेट करने से जुड़ी गाइड देखें. खास तौर पर, अगर Content-Security-Policy के उल्लंघन की रिपोर्टिंग के लिए, सिर्फ़ report-uri डायरेक्टिव का इस्तेमाल किया जा रहा है, तो सीएसपी रिपोर्टिंग के लिए माइग्रेशन के चरण देखें.

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...

कुंजियां (एंडपॉइंट के नाम)

हर कुंजी का नाम अपनी पसंद के मुताबिक रखा जा सकता है. जैसे, main-endpoint या endpoint-1. अलग-अलग रिपोर्ट टाइप के लिए, अलग-अलग नाम वाले एंडपॉइंट सेट किए जा सकते हैं. उदाहरण के लिए, my-coop-endpoint, my-csp-endpoint. इसकी मदद से, रिपोर्ट को उनके टाइप के आधार पर अलग-अलग एंडपॉइंट पर भेजा जा सकता है.

अगर आपको इंटरवेंशन, बंद होने, क्रैश की रिपोर्ट या इनमें से किसी भी रिपोर्ट का कॉम्बिनेशन चाहिए, तो default नाम का एंडपॉइंट सेट करें.

अगर Reporting-Endpoints हेडर में कोई default एंडपॉइंट तय नहीं किया गया है, तो इस तरह की रिपोर्ट नहीं भेजी जाएंगी. हालांकि, वे जनरेट की जाएंगी.

वैल्यू (यूआरएल)

हर वैल्यू आपकी पसंद का यूआरएल होता है. रिपोर्ट इसी यूआरएल पर भेजी जाएंगी. यहां सेट किया जाने वाला यूआरएल, पहले चरण में आपके चुने गए विकल्प पर निर्भर करता है.

एंडपॉइंट यूआरएल:

• यह स्लैश (/) से शुरू होना चाहिए. रिलेटिव पाथ का इस्तेमाल नहीं किया जा सकता.
• यह क्रॉस-ऑरिजिन हो सकता है. हालांकि, ऐसे मामले में रिपोर्ट के साथ क्रेडेंशियल नहीं भेजे जाते.

उदाहरण

Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"

इसके बाद, हर नाम वाले एंडपॉइंट का इस्तेमाल सही नीति में किया जा सकता है या सभी नीतियों में एक ही एंडपॉइंट का इस्तेमाल किया जा सकता है.

हेडर कहां सेट करें?

इस पोस्ट में बताए गए Reporting API के नए वर्शन में, रिपोर्ट को दस्तावेज़ों के हिसाब से स्कोप किया जाता है. इसका मतलब है कि किसी एक ऑरिजिन के लिए, अलग-अलग दस्तावेज़, जैसे कि site.example/page1 और site.example/page2, अलग-अलग एंडपॉइंट पर रिपोर्ट भेज सकते हैं.

अपनी साइट के किसी भी पेज पर होने वाले उल्लंघनों या बंद होने की रिपोर्ट पाने के लिए, सभी रिस्पॉन्स पर हेडर को मिडलवेयर के तौर पर सेट करें.

Express में इसका एक उदाहरण यहां दिया गया है:

const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;

app.use(function (request, response, next) {
  // Set up the Reporting API
  response.set(
    'Reporting-Endpoints',
    `main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
  );
  next();
});

अपनी नीतियों में बदलाव करना

Reporting-Endpoints हेडर कॉन्फ़िगर हो जाने के बाद, हर उस नीति के हेडर में report-to डायरेक्टिव जोड़ें जिसके लिए आपको उल्लंघन की रिपोर्ट चाहिए. report-to एट्रिब्यूट की वैल्यू, कॉन्फ़िगर किए गए नाम वाले एंडपॉइंट में से कोई एक होनी चाहिए.

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

बंद होने, हस्तक्षेप, और क्रैश की रिपोर्ट के लिए, report-to की ज़रूरत नहीं होती. ये रिपोर्ट, किसी भी नीति से बंधी हुई नहीं हैं. ये तब तक जनरेट होते हैं, जब तक default एंडपॉइंट सेट अप किया जाता है और इस default एंडपॉइंट पर भेजा जाता है.

उदाहरण

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint

रिपोर्टिंग सेटअप को डीबग करना

जान-बूझकर रिपोर्ट जनरेट करना

Reporting API सेट अप करते समय, आपको जान-बूझकर अपनी नीतियों का उल्लंघन करना पड़ सकता है. ऐसा इसलिए, ताकि यह देखा जा सके कि रिपोर्ट जनरेट हो रही हैं और उन्हें उम्मीद के मुताबिक भेजा जा रहा है या नहीं.

समय बचाएँ

रिपोर्ट भेजने में देरी हो सकती है. इसमें करीब एक मिनट लग सकता है. डीबग करते समय, यह ज़्यादा समय होता है. 😴 अच्छी बात यह है कि Chrome में डीबग करते समय, --short-reporting-delay फ़्लैग का इस्तेमाल किया जा सकता है. इससे रिपोर्ट जनरेट होते ही आपको मिल जाती हैं.

इस फ़्लैग को चालू करने के लिए, अपने टर्मिनल में यह निर्देश चलाएं:

YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay

DevTools का इस्तेमाल करना

Chrome में, DevTools का इस्तेमाल करके उन रिपोर्ट को देखा जा सकता है जिन्हें भेजा गया है या भेजा जाएगा.

अक्टूबर 2021 से, यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध है. इसका इस्तेमाल करने के लिए, यह तरीका अपनाएं:

1. Chrome के वर्शन 96 और इसके बाद के वर्शन का इस्तेमाल करें. यह देखने के लिए कि आपके ब्राउज़र का वर्शन कौन-सा है, chrome://version टाइप करें
2. Chrome के पता बार में chrome://flags/#enable-experimental-web-platform-features टाइप करें या चिपकाएं.
3. चालू है पर क्लिक करें.
4. अपना ब्राउज़र रीस्टार्ट करें.
5. Chrome DevTools खोलें.
6. Chrome DevTools में, सेटिंग खोलें. Experiments में जाकर, Enable Reporting API panel in the Application panel पर क्लिक करें.
7. DevTools को फिर से लोड करें.
8. पेज को फिर से लोड करें. जिस पेज पर DevTools खुला है उससे जनरेट हुई रिपोर्ट, Chrome DevTools के ऐप्लिकेशन पैनल में, Reporting API सेक्शन में दिखेंगी.

रिपोर्ट की स्थिति

स्थिति कॉलम से पता चलता है कि रिपोर्ट भेजी गई है या नहीं.

रिपोर्ट को कुछ समय बाद हटा दिया जाता है, भले ही वे सही तरीके से भेजी गई हों या नहीं.

समस्या का हल

क्या रिपोर्ट जनरेट नहीं हो रही हैं या आपके एंडपॉइंट पर उम्मीद के मुताबिक नहीं भेजी जा रही हैं? इस समस्या को हल करने के लिए, यहां कुछ सुझाव दिए गए हैं.

रिपोर्ट जनरेट नहीं की गई हैं

DevTools में दिखने वाली रिपोर्ट सही तरीके से जनरेट की गई हैं. अगर आपको जिस रिपोर्ट की ज़रूरत है वह इस सूची में नहीं दिख रही है, तो:

• अपनी नीतियों में report-to देखें. अगर इसे गलत तरीके से कॉन्फ़िगर किया गया है, तो रिपोर्ट जनरेट नहीं होगी. इसे ठीक करने के लिए, अपनी नीतियों में बदलाव करें पर जाएं. इस समस्या को हल करने का एक और तरीका है. इसके लिए, Chrome में DevTools कंसोल देखें: अगर आपको लगता है कि नीति का उल्लंघन हुआ है और कंसोल में कोई गड़बड़ी दिखती है, तो इसका मतलब है कि आपकी नीति शायद सही तरीके से कॉन्फ़िगर की गई है.
• ध्यान रखें कि इस सूची में सिर्फ़ वे रिपोर्ट दिखेंगी जो उस दस्तावेज़ के लिए जनरेट की गई थीं जिसमें DevTools खुला है. उदाहरण के लिए: अगर आपकी साइट site1.example किसी ऐसे iframe को एम्बेड करती है site2.example जो किसी नीति का उल्लंघन करता है और इस वजह से रिपोर्ट जनरेट करता है, तो यह रिपोर्ट DevTools में सिर्फ़ तब दिखेगी, जब iframe को उसकी विंडो में खोला जाएगा और उस विंडो के लिए DevTools खोला जाएगा.

रिपोर्ट जनरेट हो गई हैं, लेकिन भेजी या मिली नहीं हैं

अगर आपको DevTools में कोई रिपोर्ट दिखती है, लेकिन आपके एंडपॉइंट को वह नहीं मिलती है, तो क्या होगा?

• पक्का करें कि कम समय के लिए देरी का इस्तेमाल किया गया हो. ऐसा हो सकता है कि आपको रिपोर्ट इसलिए न दिख रही हो, क्योंकि उसे अब तक भेजा ही न गया हो!

• अपने Reporting-Endpoints हेडर कॉन्फ़िगरेशन की जांच करें. अगर इसमें कोई समस्या है, तो सही तरीके से जनरेट की गई रिपोर्ट नहीं भेजी जाएगी. इस मामले में, DevTools में रिपोर्ट का स्टेटस Queued रहेगा. हालांकि, रिपोर्ट डिलीवर करने की कोशिश किए जाने पर, यह Pending पर जा सकता है और फिर तुरंत Queued पर वापस आ सकता है. इसकी वजह कुछ आम गलतियां हो सकती हैं:

• एंडपॉइंट का इस्तेमाल किया गया है, लेकिन उसे कॉन्फ़िगर नहीं किया गया है. उदाहरण:

 Document-Policy: document-write=?0;report-to=endpoint-1;
 Reporting-Endpoints: default="https://reports.example/default"

• default एंडपॉइंट मौजूद नहीं है. कुछ तरह की रिपोर्ट, जैसे कि बंद होने वाली सुविधाओं और इंटरवेंशन की रिपोर्ट, सिर्फ़ default नाम वाले एंडपॉइंट को भेजी जाएंगी. ज़्यादा जानकारी के लिए, Reporting-Endpoints हेडर कॉन्फ़िगर करना लेख पढ़ें.

• नीति के हेडर सिंटैक्स में मौजूद समस्याएं ढूंढें. जैसे, कोटेशन मार्क मौजूद न होना. जानकारी देखें.

• देखें कि आपका एंडपॉइंट, आने वाले अनुरोधों को मैनेज कर सकता है या नहीं.

  • पक्का करें कि आपका एंडपॉइंट, सीओआरएस प्रीफ़्लाइट अनुरोधों के साथ काम करता हो. अगर ऐसा नहीं होता है, तो उसे रिपोर्ट नहीं मिल सकतीं.

  • अपने एंडपॉइंट के काम करने के तरीके की जांच करें. इसके लिए, मैन्युअल तरीके से रिपोर्ट जनरेट करने के बजाय, अपने एंडपॉइंट पर ऐसे अनुरोध भेजकर ब्राउज़र को एम्युलेट किया जा सकता है जो ब्राउज़र से भेजे जाने वाले अनुरोधों जैसे दिखते हैं. यह कमांड चलाएं:

  curl --header "Content-Type: application/reports+json" \
    --request POST \
    --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \
    YOUR_ENDPOINT
  

  आपके एंडपॉइंट को सक्सेस कोड (200 या कोई अन्य सक्सेस रिस्पॉन्स कोड 2xx) के साथ जवाब देना चाहिए. अगर ऐसा नहीं होता है, तो इसके कॉन्फ़िगरेशन में कोई समस्या है.

शिकायत करने के अन्य तरीके

सिर्फ़ रिपोर्ट करना

-Report-Only नीति के हेडर और Reporting-Endpoints एक साथ काम करते हैं.

Reporting-Endpoints में कॉन्फ़िगर किए गए और Content-Security-Policy, Cross-Origin-Embedder-Policy, और Cross-Origin-Opener-Policy के report-to फ़ील्ड में बताए गए एंडपॉइंट को इन नीतियों का उल्लंघन होने पर रिपोर्ट मिलेंगी.

Reporting-Endpoints में कॉन्फ़िगर किए गए एंडपॉइंट, Content-Security-Policy-Report-Only, Cross-Origin-Embedder-Policy-Report-Only, और Cross-Origin-Opener-Policy-Report-Only के report-to फ़ील्ड में भी बताए जा सकते हैं. इन नीतियों का उल्लंघन होने पर, उन्हें रिपोर्ट भी मिलेंगी.

दोनों ही मामलों में रिपोर्ट भेजी जाती हैं. हालांकि, -Report-Only हेडर, नीतियों को लागू नहीं करते. इसका मतलब है कि न तो कुछ काम करना बंद करेगा और न ही ब्लॉक होगा. हालांकि, आपको उन चीज़ों की रिपोर्ट मिलेंगी जो काम करना बंद कर सकती थीं या ब्लॉक हो सकती थीं.

ReportingObserver

ReportingObserver JavaScript API की मदद से, क्लाइंट-साइड की चेतावनियों को देखा जा सकता है.

ReportingObserver और Reporting-Endpoints हेडर, ऐसी रिपोर्ट जनरेट करते हैं जो एक जैसी दिखती हैं. हालांकि, इनके इस्तेमाल के उदाहरण थोड़े अलग होते हैं.

ReportingObserver का इस्तेमाल तब करें, जब:

• आपको सिर्फ़ बंद की गई सुविधाओं या ब्राउज़र के इंटरवेंशन को मॉनिटर करना है. ReportingObserver, क्लाइंट-साइड चेतावनियां दिखाता है. जैसे, बंद होने वाली सुविधाएं और ब्राउज़र इंटरवेंशन. हालांकि, Reporting-Endpoints के उलट, यह किसी अन्य तरह की रिपोर्ट कैप्चर नहीं करता. जैसे, सीएसपी या सीओओपी/सीओईपी के उल्लंघन.
• आपको इन उल्लंघनों पर रीयल-टाइम में कार्रवाई करनी होगी. ReportingObserver की मदद से, उल्लंघन वाले इवेंट में कॉलबैक अटैच किया जा सकता है.
• आपको डीबग करने में मदद पाने के लिए, कस्टम कॉल बैक का इस्तेमाल करके, रिपोर्ट में अतिरिक्त जानकारी अटैच करनी है.

एक और अंतर यह है कि ReportingObserver को सिर्फ़ क्लाइंट-साइड पर कॉन्फ़िगर किया जाता है: इसका इस्तेमाल तब भी किया जा सकता है, जब आपके पास सर्वर-साइड हेडर पर कंट्रोल न हो और Reporting-Endpoints को सेट न किया जा सके.

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

• Reporting API के वर्शन 0 से वर्शन 1 पर माइग्रेट करने से जुड़ी गाइड
• ReportingObserver
• जानकारी: लेगसी Reporting API (v0)
• जानकारी: नया Reporting API (v1)

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