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

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

Maud Nalpas

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

इससे आपको यह एलान करने की सुविधा मिलती है कि एचटीटीपी हेडर के ज़रिए, आपको किस चीज़ पर नज़र रखनी है और ब्राउज़र से काम करता है.

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

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

डेमो और कोड

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

खास जानकारी

मान लें कि आपकी साइट, 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 का इस्तेमाल करना

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

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

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

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

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

• रिपोर्ट-यूरी
• यूरिपोर्ट

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

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

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

दूसरा विकल्प: अपना रिपोर्ट कलेक्टर बनाना और उसे ऑपरेट करना

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

1. बॉयलरप्लेट रिपोर्ट कलेक्टर पर जाएं.

2. प्रोजेक्ट में बदलाव करने के लिए, बदलाव करने के लिए रीमिक्स करें पर क्लिक करें.

3. अब आपका क्लोन बन गया है! इसे अपनी पसंद के मुताबिक बनाया जा सकता है.

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

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

मान (यूआरएल)

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

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

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

उदाहरण

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-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

कोड का उदाहरण

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

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

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

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 में सेटिंग खोलें. 'प्रयोग' में जाकर, रिपोर्टिंग एपीआई पैनल चालू करें ऐप्लिकेशन पैनल.
7. DevTools को फिर से लोड करें.
8. अपना पेज फिर से लोड करें. DevTools पेज पर खुलने वाली रिपोर्ट में, Chrome DevTools में मौजूद है' रिपोर्टिंग 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 नाम वाले एंडपॉइंट पर भेजी जाएंगी. ज़्यादा जानकारी के लिए, रिपोर्टिंग-एंडपॉइंट हेडर कॉन्फ़िगर करना लेख पढ़ें.

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

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

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

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

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

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

दोनों मामलों में रिपोर्ट भेजी जाती हैं. हालांकि, -Report-Only हेडर नीतियां: किसी भी चीज़ पर असर नहीं पड़ेगा या असल में वह ब्लॉक नहीं होगा, लेकिन आपको रिपोर्ट में बताया जाएगा कि क्या उल्लंघन हुआ या क्या ब्लॉक किया गया.

ReportingObserver

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

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

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

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

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

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

• रिपोर्टिंग एपीआई v0 से v1 में माइग्रेशन गाइड
• ReportingObserver
• खास जानकारी: लेगसी Reporting API (v0)
• खास जानकारी: नया Reporting API (v1)

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