इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

Maud Nalpas

चेतावनी:

इस एपीआई गाइड में, Reporting API (v1) के इस्तेमाल के ज़्यादा उदाहरण दिए गए हैं. इसमें Reporting-Endpoints हेडर का इस्तेमाल किया जाता है.

अगर लेगसी Reporting API (Report-To हेडर) का इस्तेमाल किया जा रहा है, तो एपीआई माइग्रेशन के बारे में पढ़ें.

क्या आपको नेटवर्क की गड़बड़ी का पता लगाने की सुविधा से जुड़ा दस्तावेज़ चाहिए? इसके बजाय, Networkगड़बड़ी लॉग करने की सुविधा पर जाएं.

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

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

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

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

डेमो और कोड

Reporting API को Chrome 96 और इसके बाद के वर्शन (Chrome के बीटा वर्शन या कैनरी के अक्टूबर 2021 से) वर्शन के हिसाब से देखें.

इसे आज़माएं:

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

खास जानकारी

रिपोर्ट जनरेट करने से लेकर रिपोर्ट जनरेट करने तक, जिसे डेवलपर ऐक्सेस करता है — रिपोर्ट कैसे जनरेट होती हैं और कैसे भेजी जाती हैं.

मान लें कि आपकी साइट 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"
}

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

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

रिपोर्ट का टाइप	ऐसी स्थिति का उदाहरण जिसमें रिपोर्ट जनरेट की जाएगी
सीएसपी उल्लंघन (सिर्फ़ लेवल 3)	आपने अपने किसी एक पेज पर `Content-Security-Policy` (सीएसपी) सेट किया है. हालांकि, पेज ऐसी स्क्रिप्ट लोड करने की कोशिश कर रहा है जो आपके सीएसपी को अनुमति नहीं देती.
सीओओपी का उल्लंघन	आपने पेज पर `Cross-Origin-Opener-Policy` सेट किया है, लेकिन कोई क्रॉस-ऑरिजिन विंडो, सीधे दस्तावेज़ के साथ इंटरैक्ट करने की कोशिश कर रही है.
सीओईपी का उल्लंघन	आपने पेज पर `Cross-Origin-Embedder-Policy` सेट किया है, लेकिन दस्तावेज़ में ऐसा क्रॉस-ऑरिजिन iframe शामिल है जिसे क्रॉस-ऑरिजिन दस्तावेज़ों से लोड होने के लिए ऑप्ट इन नहीं किया गया है.
दस्तावेज़ की नीति का उल्लंघन	पेज पर एक दस्तावेज़ की नीति मौजूद है, जो `document.write` के इस्तेमाल को रोकती है. हालांकि, कोई स्क्रिप्ट `document.write` को कॉल करने की कोशिश करती है.
अनुमतियों की नीति का उल्लंघन	पेज पर एक अनुमति नीति मौजूद है, जो माइक्रोफ़ोन के इस्तेमाल और ऑडियो इनपुट का अनुरोध करने वाली स्क्रिप्ट को रोकती है.
बंद करने की चेतावनी	पेज ऐसे एपीआई का इस्तेमाल कर रहा है जो अब काम नहीं करता या उसे बंद कर दिया जाएगा. यह पेज इसे सीधे तौर पर या टॉप लेवल की तीसरे पक्ष की स्क्रिप्ट के ज़रिए कॉल करता है.
इंटरवेंशन	पेज कुछ ऐसा करने की कोशिश कर रहा है जिसे ब्राउज़र सुरक्षा, परफ़ॉर्मेंस या उपयोगकर्ता अनुभव की वजहों से पूरा नहीं करने का फ़ैसला करता है. Chrome का उदाहरण: पेज धीमे नेटवर्क पर `document.write` का इस्तेमाल करता है या ऐसे क्रॉस-ऑरिजिन फ़्रेम में `navigator.vibrate` को कॉल करता है जिससे उपयोगकर्ता ने अभी तक इंटरैक्ट नहीं किया है.
दुर्घटना	आपकी साइट खुली होने पर ब्राउज़र क्रैश हो जाता है.

रिपोर्ट

रिपोर्ट कैसी दिखती हैं?

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

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"
  }
]

इनमें से हर रिपोर्ट में आपको यह डेटा दिखेगा:

फ़ील्ड	ब्यौरा
`age`	रिपोर्ट के टाइमस्टैंप और मौजूदा समय के बीच मिलीसेकंड की संख्या.
`body`	रिपोर्ट का असल डेटा, जिसे JSON स्ट्रिंग में क्रम से लगाया जाता है. किसी रिपोर्ट की `body` में शामिल फ़ील्ड को, रिपोर्ट की `type` से तय किया जाता है. ⚠️ अलग-अलग तरह की रिपोर्ट में अलग-अलग तरीके होते हैं. हर तरह की रिपोर्ट का मुख्य हिस्सा देखने के लिए, डेमो रिपोर्टिंग एंडपॉइंट पर जाएं और उदाहरण के तौर पर दी गई रिपोर्ट जनरेट करने के लिए, निर्देशों का पालन करें.
`type`	रिपोर्ट टाइप, जैसे कि `csp-violation` या `coep`.
`url`	उस दस्तावेज़ या वर्कर का पता जिससे रिपोर्ट बनाई गई थी. उपयोगकर्ता नाम, पासवर्ड, और फ़्रैगमेंट जैसे संवेदनशील डेटा को इस यूआरएल से हटा दिया जाता है.
`user_agent`	उस अनुरोध का `User-Agent` हेडर जिससे रिपोर्ट जनरेट हुई थी.

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

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

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

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

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

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

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

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

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

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

'रोक लगाने' का उदाहरण

अगर आपके पेज पर Reporting-Endpoints हेडर सेट अप किया गया है: आपके पेज पर चल रही तीसरे पक्ष की स्क्रिप्ट, काम न करने वाले ऐसे एपीआई को कॉल कर सकती हैं जो अब काम नहीं करता. आपके पेज में एम्बेड किए गए iframe के ज़रिए कॉल किया गया, काम न करने वाला एपीआई आपके एंडपॉइंट पर रिपोर्ट नहीं किया जाएगा. इस्तेमाल पर रोक लगाने से जुड़ी रिपोर्ट सिर्फ़ तब जनरेट होगी, जब iframe सर्वर ने रिपोर्टिंग-एंडपॉइंट सेट अप किया हो. साथ ही, यह रिपोर्ट उस एंडपॉइंट पर भेजी जाएगी जिसे iframe के सर्वर ने सेट अप किया है. — अगर आपके पेज पर Reporting-Endpoints हेडर सेट अप किया गया है: तो आपके पेज पर चल रही तीसरे पक्ष की स्क्रिप्ट के ज़रिए काम न करने वाले एपीआई को आपके एंडपॉइंट पर रिपोर्ट किया जाएगा. आपके पेज में एम्बेड किए गए iframe के ज़रिए कॉल किया गया, काम न करने वाला एपीआई आपके एंडपॉइंट पर रिपोर्ट नहीं किया जाएगा. इस्तेमाल पर रोक लगाने से जुड़ी रिपोर्ट सिर्फ़ तब जनरेट होगी, जब iframe सर्वर ने रिपोर्टिंग-एंडपॉइंट सेट अप किया हो. साथ ही, यह रिपोर्ट उस एंडपॉइंट पर भेजी जाएगी जिसे iframe के सर्वर ने सेट अप किया है.

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

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

रिपोर्ट का टाइप	Chrome	Chrome iOS	Safari	Firefox	Edge
सीएसपी का उल्लंघन (सिर्फ़ लेवल 3 के लिए)*	✔ हां	✔ हां	✔ हां	✘ नहीं	✔ हां
नेटवर्क की गड़बड़ी का डेटा लॉग करने में	✘ नहीं	✘ नहीं	✘ नहीं	✘ नहीं	✘ नहीं
सीओओपी/सीओईपी का उल्लंघन	✔ हां	✘ नहीं	✔ हां	✘ नहीं	✔ हां
दूसरी तरह के सभी मामले: दस्तावेज़ से जुड़ी नीति का उल्लंघन, रुकना, रुकावट डालना, क्रैश होना	✔ हां	✘ नहीं	✘ नहीं	✘ नहीं	✔ हां

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

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

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

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

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

पहला विकल्प: रिपोर्ट कलेक्टर सेवा का इस्तेमाल करना

रिपोर्ट कलेक्टर सेवाओं के कुछ उदाहरण:

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

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

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

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

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

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

अगर बॉयलरप्लेट का इस्तेमाल नहीं किया जा रहा है और शुरुआत से अपना सर्वर बनाया जा रहा है, तो:

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

तीसरा विकल्प: विकल्प 1 और 2 को जोड़ना

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

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

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 दोनों को सेट करना सही रहता है. डेटा को दूसरी जगह भेजने से जुड़ी गाइड में ज़्यादा जानकारी देखें. खास तौर पर, अगर सिर्फ़ report-uri डायरेक्टिव की मदद से, Content-Security-Policy के उल्लंघनों की रिपोर्टिंग का इस्तेमाल किया जा रहा है, तो सीएसपी रिपोर्टिंग के लिए माइग्रेशन के तरीके देखें.

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 एंडपॉइंट के बारे में जानकारी नहीं मिलती है, तो इस तरह की रिपोर्ट नहीं भेजी जाएंगी. हालांकि, इन्हें जनरेट किया जाएगा.

अहम जानकारी: default, फ़ॉलबैक एंडपॉइंट होने के बावजूद, इसका नाम नहीं है. उदाहरण के लिए, अगर आपने Document-Policy के लिए report-to my-endpoint को सेट अप किया है और Reporting-Endpoints में my-endpoint के बारे में बताने के लिए छोड़ दिया है, तो Document-Policy उल्लंघनों की रिपोर्ट जनरेट हो जाएंगी. हालांकि, उन्हें जनरेट नहीं किया जाएगा, क्योंकि ब्राउज़र को यह नहीं पता कि उन्हें कहां भेजना है.

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

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

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

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

उदाहरण

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 जैसे अलग-अलग दस्तावेज़ अलग-अलग एंडपॉइंट पर रिपोर्ट भेज सकते हैं.

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

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

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 API (Report-To हेडर) से अलग है, जहां किसी एक पेज के लिए "ऐंबियंट" एंडपॉइंट सेट किया जा सकता है. साथ ही, एक ही ऑरिजिन पर मौजूद किसी भी पेज के लिए, रिपोर्ट अपने-आप मिल सकती हैं. लेगसी Reporting API से नए Reporting API में माइग्रेट करने के लिए, डेटा को दूसरी जगह भेजने से जुड़ी गाइड देखें.

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

अब Reporting-Endpoints हेडर कॉन्फ़िगर हो गया है, तो हर उस नीति हेडर में report-to डायरेक्टिव जोड़ें जिसके लिए आपको उल्लंघन की रिपोर्ट चाहिए. 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

चेतावनी: report-to सिंटैक्स को सही तरीके से लिखना मुश्किल हो सकता है, क्योंकि सभी नीतियों में एक ही हेडर स्ट्रक्चर का इस्तेमाल नहीं किया जाता. नीति के आधार पर, सही सिंटैक्स report-to=main-endpoint या report-to main-endpoint हो सकता है. कोड के उदाहरण देखने के लिए, डेमो पर जाएं.

कोड का उदाहरण

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

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

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

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

समय बचाएं

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

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

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

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

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

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

Chrome के वर्शन 96 और इसके बाद के वर्शन का इस्तेमाल करें (अपने ब्राउज़र में chrome://version टाइप करके देखें)
Chrome के यूआरएल बार में chrome://flags/#enable-experimental-web-platform-features टाइप करें या चिपकाएं.
चालू है पर क्लिक करें.
ब्राउज़र रीस्टार्ट करें.
Chrome DevTools खोलें.
Chrome DevTools में सेटिंग खोलें. प्रयोग में जाकर, ऐप्लिकेशन पैनल में Reporting API पैनल चालू करें पर क्लिक करें.
DevTools फिर से लोड करें.
अपना पेज फिर से लोड करें. DevTools पेज से जनरेट की गई रिपोर्ट, रिपोर्टिंग एपीआई में, Chrome DevTools के ऐप्लिकेशन पैनल में दिखेंगी.

DevTools की रिपोर्ट का स्क्रीनशॉट — Chrome DevTools आपके पेज पर जनरेट की गई रिपोर्ट और उनकी स्थिति दिखाता है.

शिकायत की स्थिति

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

स्थिति	ब्यौरा
`Success`	ब्राउज़र ने रिपोर्ट भेज दी है और एंडपॉइंट ने सक्सेस कोड (`200` या दूसरा सक्सेस रिस्पॉन्स कोड `2xx`) के साथ जवाब दिया है.
`Pending`	ब्राउज़र फ़िलहाल रिपोर्ट भेजने की कोशिश कर रहा है.
`Queued`	रिपोर्ट जनरेट हो गई है और फ़िलहाल ब्राउज़र इसे भेजने की कोशिश नहीं कर रहा है. रिपोर्ट, इन दोनों में से किसी एक मामले में `Queued` के तौर पर दिखती है: यह रिपोर्ट नई है और ब्राउज़र यह पता लगाने का इंतज़ार कर रहा है कि और रिपोर्ट मिलती हैं या नहीं. इसके बाद, उसे भेजने की कोशिश की जाती है. यह रिपोर्ट नई नहीं है. ब्राउज़र ने इस रिपोर्ट को भेजने की पहले ही कोशिश की है. हालांकि, वह प्रोसेस नहीं कर सका और दोबारा कोशिश करने से पहले इंतज़ार कर रहा है.
`MarkedForRemoval`	कुछ समय तक फिर से कोशिश करने के बाद (`Queued`), ब्राउज़र ने रिपोर्ट भेजने की कोशिश करना बंद कर दिया है और जल्द ही उसे भेजी जाने वाली रिपोर्ट की सूची से हटा दिया जाएगा.

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

अहम जानकारी: Queued की स्थिति हमेशा जानकारी देने वाली नहीं होती, क्योंकि इससे यह साफ़ तौर पर नहीं पता चलता कि मैसेज भेजना विफल रहा है या अभी तक उसकी कोशिश नहीं की गई है. रिपोर्ट में देरी का इस्तेमाल करने से मदद मिलती है: इस मामले में जो रिपोर्ट Queued बनी रहती है उसका मतलब है कि मैसेज नहीं भेजा जा सका.

समस्या हल करना

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

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

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

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

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

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

अहम जानकारी: रिपोर्ट को किसी साइट से नहीं, बल्कि ब्राउज़र खुद ही आउट-ऑफ़-बैंड भेजता है. इस वजह से, रिपोर्ट वाले POST अनुरोध आपके डेवलपर टूल के नेटवर्क पैनल में नहीं दिखते.

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

कोड में कोई गलती है

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

दस्तावेज़ से जुड़ी नीति के उल्लंघन की रिपोर्ट endpoint-1 को भेजी जानी चाहिए. हालांकि, इस एंडपॉइंट नाम को Reporting-Endpoints में कॉन्फ़िगर नहीं किया गया है.

default एंडपॉइंट मौजूद नहीं है. कुछ तरह की रिपोर्ट, जैसे कि बंद करने और इंटरवेंशन की रिपोर्ट सिर्फ़ default नाम के एंडपॉइंट पर भेजी जाएंगी. ज़्यादा जानकारी के लिए, रिपोर्टिंग-एंडपॉइंट हेडर कॉन्फ़िगर करना लेख पढ़ें.
अपने नीति हेडर के सिंटैक्स में समस्याओं पर नज़र रखें, जैसे कि कोटेशन मौजूद न होना. जानकारी देखें.
पक्का करें कि आपका एंडपॉइंट, आने वाले अनुरोधों को मैनेज कर सकता हो.
- पक्का करें कि आपके एंडपॉइंट पर, सीओआरएस प्रीफ़्लाइट का अनुरोध काम करता हो. अगर ऐसा नहीं है, तो उसे रिपोर्ट नहीं मिलेंगी.
- अपने एंडपॉइंट के व्यवहार की जांच करें. ऐसा करने के लिए, मैन्युअल तरीके से रिपोर्ट जनरेट करने के बजाय, एंडपॉइंट के अनुरोधों पर भेजकर ब्राउज़र की नकल की जा सकती है. ये अनुरोध ऐसे दिखते हैं जो ब्राउज़र की मदद से भेजा जाता है. इसे चलाएं:
```
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 हेडर, नीतियों को लागू नहीं करते: इससे कुछ भी नहीं मिटेगा या असल में उन्हें ब्लॉक नहीं किया जाएगा. हालांकि, आपको इस बात की रिपोर्ट मिलेगी कि क्या हुआ या ब्लॉक हुआ है.

ध्यान दें: अगर -Report-Only हेडर का इस्तेमाल किया जा रहा है और लेगसी हेडर Report-To के ज़रिए रिपोर्टिंग एंडपॉइंट कॉन्फ़िगर किए हैं, तो हो सके, तो Reporting-Endpoints पर माइग्रेट करें. ज़्यादा जानकारी के लिए, डेटा को दूसरी जगह भेजने से जुड़ी गाइड पढ़ें.

`ReportingObserver`

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

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

ReportingObserver का इस्तेमाल करें, अगर:

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

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

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

Unsplash पर Nine Koepfer / @enka80 की हीरो इमेज. इसमें बदलाव किया गया. इस लेख पर मिली समीक्षाओं और सुझावों के लिए, इयन क्लेलैंड, ईजी कितामुरा, और मिलिका मिहाजलिया का बहुत-बहुत धन्यवाद.

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

डेमो और कोड

खास जानकारी

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

रिपोर्ट

रिपोर्ट कैसी दिखती हैं?

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

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

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

'रोक लगाने' का उदाहरण

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

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

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

पहला विकल्प: रिपोर्ट कलेक्टर सेवा का इस्तेमाल करना

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

तीसरा विकल्प: विकल्प 1 और 2 को जोड़ना

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

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

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

उदाहरण

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

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

उदाहरण

कोड का उदाहरण

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

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

समय बचाएं

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

शिकायत की स्थिति

समस्या हल करना

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

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

इससे जुड़ी शिकायत के तरीके

रिपोर्ट-ओनली

ReportingObserver

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

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

`ReportingObserver`