सुरक्षा उल्लंघनों, काम न करने वाले एपीआई कॉल वगैरह पर नज़र रखने के लिए Reporting API का इस्तेमाल करें.
कुछ गड़बड़ियां सिर्फ़ प्रोडक्शन के दौरान होती हैं. आपको गेम स्थानीय तौर पर या डेवलपमेंट के दौरान नहीं दिखेगा, क्योंकि असली उपयोगकर्ता, असल नेटवर्क, और असली डिवाइस गेम बदल देते हैं. 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"
}
इस्तेमाल के उदाहरण और रिपोर्ट टाइप
रिपोर्टिंग एपीआई को कॉन्फ़िगर करके, अपनी पूरी साइट पर होने वाली कई तरह की दिलचस्प चेतावनियों या समस्याओं पर नज़र रखी जा सकती है:
रिपोर्ट का टाइप | ऐसी स्थिति का उदाहरण जिसमें रिपोर्ट जनरेट की जाएगी |
---|---|
सीएसपी उल्लंघन (सिर्फ़ लेवल 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 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
एंडपॉइंट के बारे में जानकारी नहीं मिलती है, तो इस तरह की रिपोर्ट नहीं भेजी जाएंगी. हालांकि, इन्हें जनरेट किया जाएगा.
वैल्यू (यूआरएल)
हर वैल्यू आपकी पसंद का यूआरएल होता है, जहां रिपोर्ट भेजी जाएंगी. यहां सेट किया जाने वाला यूआरएल, इस बात पर निर्भर करता है कि आपने पहले चरण में क्या फ़ैसला लिया था.
एंडपॉइंट यूआरएल:
- स्लैश (
/
) से शुरू होना चाहिए. मिलते-जुलते पाथ का इस्तेमाल नहीं किया जा सकता. - क्रॉस-ऑरिजिन हो सकता है. हालांकि, ऐसे मामलों में रिपोर्ट के साथ क्रेडेंशियल नहीं भेजे जाते.
उदाहरण
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
कोड का उदाहरण
इन सभी चीज़ों को देखने के लिए, नीचे एक नोड सर्वर का उदाहरण दिया गया है. यह सर्वर एक्सप्रेस का इस्तेमाल करता है. साथ ही, इस लेख में बताए गए सभी हिस्सों को एक साथ रखता है. इसमें, अलग-अलग तरह की रिपोर्ट के लिए रिपोर्टिंग को कॉन्फ़िगर करने का तरीका बताया गया है और नतीजे दिखाए गए हैं.
रिपोर्टिंग सेटअप को डीबग करना
जान-बूझकर रिपोर्ट जनरेट करना
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 के ऐप्लिकेशन पैनल में दिखेंगी.
शिकायत की स्थिति
स्टेटस कॉलम से पता चलता है कि रिपोर्ट भेजी गई है या नहीं.
स्थिति | ब्यौरा |
---|---|
Success |
ब्राउज़र ने रिपोर्ट भेज दी है और एंडपॉइंट ने सक्सेस कोड (200 या दूसरा सक्सेस रिस्पॉन्स कोड 2xx ) के साथ जवाब दिया है. |
Pending |
ब्राउज़र फ़िलहाल रिपोर्ट भेजने की कोशिश कर रहा है. |
Queued |
रिपोर्ट जनरेट हो गई है और फ़िलहाल ब्राउज़र इसे भेजने की कोशिश नहीं कर रहा है. रिपोर्ट, इन दोनों में से किसी एक मामले में Queued के तौर पर दिखती है:
|
MarkedForRemoval |
कुछ समय तक फिर से कोशिश करने के बाद (Queued ), ब्राउज़र ने रिपोर्ट भेजने की कोशिश करना बंद कर दिया है और जल्द ही उसे भेजी जाने वाली रिपोर्ट की सूची से हटा दिया जाएगा. |
रिपोर्ट कुछ समय बाद निकाल दी जाती हैं, भले ही वे सफलतापूर्वक भेजी गई हों या नहीं.
समस्या हल करना
क्या रिपोर्ट जनरेट नहीं होती या आपके एंडपॉइंट पर उम्मीद के मुताबिक नहीं भेजी जाती हैं? इस समस्या को हल करने के लिए यहां कुछ सलाह दी गई हैं.
रिपोर्ट जनरेट नहीं की गईं
DevTools में दिखने वाली रिपोर्ट सही तरीके से जनरेट की गई हैं. अगर आपकी उम्मीद के मुताबिक रिपोर्ट इस सूची में नहीं दिखती है, तो:
- अपनी नीतियों में
report-to
देखें. अगर इसे गलत तरीके से कॉन्फ़िगर किया गया है, तो रिपोर्ट जनरेट नहीं होगी. इसे ठीक करने के लिए, अपनी नीतियों में बदलाव करें पर जाएं. इस समस्या को हल करने का एक और तरीका Chrome में DevTools कंसोल की जांच करना है: अगर कंसोल में, आपकी उम्मीद के मुताबिक उल्लंघन के लिए कोई गड़बड़ी पॉप-अप होती है, तो इसका मतलब है कि आपकी नीति सही तरीके से कॉन्फ़िगर की गई है. - ध्यान रखें कि दस्तावेज़ DevTools के लिए जनरेट की गई रिपोर्ट ही
इस सूची में दिखेंगी. एक उदाहरण: अगर आपकी साइट
site1.example
, किसी ऐसे iframesite2.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
में कॉन्फ़िगर किए गए और 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 v0 से v1 तक की माइग्रेशन गाइड
- ReportingObserver
- खास जानकारी: लेगसी Reporting API (v0)
- खास जानकारी: नया Reporting API (v1)
Unsplash पर Nine Koepfer / @enka80 की हीरो इमेज. इसमें बदलाव किया गया. इस लेख पर मिली समीक्षाओं और सुझावों के लिए, इयन क्लेलैंड, ईजी कितामुरा, और मिलिका मिहाजलिया का बहुत-बहुत धन्यवाद.