ब्यौरा
chrome.declarativeNetRequest
एपीआई का इस्तेमाल, नेटवर्क के अनुरोधों को ब्लॉक करने या उनमें बदलाव करने के लिए किया जाता है. ऐसा, डिक्लेरेटिव टोन वाले नियमों के बारे में बताकर किया जाता है. इसकी मदद से, एक्सटेंशन नेटवर्क के अनुरोधों में बदलाव किए बिना, उनका कॉन्टेंट देखे बिना और नेटवर्क के अनुरोधों में बदलाव कर सकते हैं. इस तरह, एक्सटेंशन की निजता बनाए रखने में मदद मिलती है.
अनुमतियां
declarativeNetRequest
declarativeNetRequestWithHostAccess
"declarativeNetRequest
" और "declarativeNetRequestWithHostAccess
" अनुमतियां
वे एक जैसी सुविधाएं देते हैं. इनके बीच का अंतर तब होता है, जब अनुमतियां
अनुरोध किया गया है या स्वीकार किया गया है.
"declarativeNetRequest"
- इंस्टॉल के समय, अनुमति से जुड़ी चेतावनी ट्रिगर करता है, लेकिन सीधे तौर पर इन चीज़ों का ऐक्सेस देता है
allow
,allowAllRequests
, औरblock
नियम. अगर हो सके, तो इसका इस्तेमाल करें होस्ट का पूरा ऐक्सेस मांगने की ज़रूरत होती है. "declarativeNetRequestFeedback"
- यह नीति पैक नहीं किए गए एक्सटेंशन, खास तौर पर
getMatchedRules()
औरonRuleMatchedDebug
के लिए, डीबग करने की सुविधाएं चालू करती है. "declarativeNetRequestWithHostAccess"
- इंस्टॉल के समय, अनुमति से जुड़ी चेतावनी नहीं दिखती है, लेकिन आपको होस्ट से अनुरोध करना होगा किसी होस्ट पर कोई कार्रवाई करने से पहले, अनुमतियों को कॉन्फ़िगर करें. यह यह तब ठीक होगा, जब आपको ऐसा एक्सटेंशन जिसके पास होस्ट की अनुमतियां पहले से ही मौजूद हैं. इसके लिए, अतिरिक्त जानकारी जनरेट नहीं की जाती चेतावनियां.
उपलब्धता
मेनिफ़ेस्ट
पहले बताई गई अनुमतियों के अलावा, कुछ खास तरह के रूलसेट, खास तौर पर स्टैटिक नियमसेट के लिए, "declarative_net_request"
मेनिफ़ेस्ट कुंजी की जानकारी देना ज़रूरी होता है. यह एक ऐसी डिक्शनरी होनी चाहिए जिसमें एक कुंजी हो, जिसे "rule_resources"
कहते हों. यह कुंजी एक कलेक्शन है, जिसमें Ruleset
टाइप की डिक्शनरी हैं, जैसा कि यहां दिखाया गया है. (ध्यान दें कि 'Ruleset' नाम मेनिफ़ेस्ट के JSON में नहीं दिखता, क्योंकि यह सिर्फ़ एक कलेक्शन है.) स्टैटिक रूलसेट के बारे में इस दस्तावेज़ में आगे बताया गया है.
{
"name": "My extension",
...
"declarative_net_request" : {
"rule_resources" : [{
"id": "ruleset_1",
"enabled": true,
"path": "rules_1.json"
}, {
"id": "ruleset_2",
"enabled": false,
"path": "rules_2.json"
}]
},
"permissions": [
"declarativeNetRequest",
"declarativeNetRequestFeedback",
],
"host_permissions": [
"http://www.blogger.com/*",
"http://*.google.com/*"
],
...
}
नियम और रूलसेट
इस एपीआई का इस्तेमाल करने के लिए, एक या एक से ज़्यादा नियमसेट तय करें. नियमसेट में नियमों की एक कैटगरी होती है. किसी एक नियम में इनमें से कोई एक काम किया जा सकता है:
- नेटवर्क अनुरोध को ब्लॉक करें.
- स्कीमा को http से https में अपग्रेड करें.
- किसी भी अनुरोध को ब्लॉक होने से रोकें. इसके लिए, ब्लॉक किए गए मिलते-जुलते नियमों को नज़रअंदाज़ करें.
- नेटवर्क अनुरोध को रीडायरेक्ट करना.
- अनुरोध या रिस्पॉन्स हेडर में बदलाव करें.
नियम सेट तीन तरह के होते हैं, जिन्हें अलग-अलग तरीकों से मैनेज किया जाता है.
- डाइनैमिक
- यह सुविधा सभी ब्राउज़र सेशन और एक्सटेंशन के अपग्रेड पर काम करती है. साथ ही, एक्सटेंशन के इस्तेमाल के दौरान, इन्हें JavaScript का इस्तेमाल करके मैनेज किया जाता है.
- सेशन
- ब्राउज़र के बंद होने और एक्सटेंशन का नया वर्शन इंस्टॉल होने पर हटाया गया. जब एक्सटेंशन का इस्तेमाल किया जा रहा हो, तब सेशन के नियमों को JavaScript का इस्तेमाल करके मैनेज किया जाता है.
- स्थिर
- एक्सटेंशन के इंस्टॉल या अपग्रेड होने के बाद, पैकेज के साथ-साथ इंस्टॉल और अपडेट हो जाते हैं. स्टैटिक नियम, JSON फ़ॉर्मैट में बनाई गई नियम फ़ाइलों में सेव किए जाते हैं और मेनिफ़ेस्ट फ़ाइल में दिखते हैं.
डाइनैमिक और सेशन के स्कोप वाले नियमसेट
जब एक्सटेंशन का इस्तेमाल किया जा रहा हो, तब डाइनैमिक और सेशन के नियमसेट, JavaScript का इस्तेमाल करके मैनेज किए जाते हैं.
- डाइनैमिक नियम, सभी ब्राउज़र सेशन और एक्सटेंशन अपग्रेड पर लागू रहते हैं.
- ब्राउज़र बंद होने और एक्सटेंशन का नया वर्शन इंस्टॉल होने पर, सेशन के नियम हटा दिए जाते हैं.
हर तरह के नियमसेट का सिर्फ़ एक टाइप है. कोई एक्सटेंशन updateDynamicRules()
और updateSessionRules()
को कॉल करके, नियमों को डाइनैमिक तौर पर जोड़ या हटा सकता है, बशर्ते नियम की सीमाएं पार न हुई हों. नियम की सीमाओं के बारे में जानने के लिए, नियम की सीमाएं देखें. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.
स्टैटिक नियमसेट
डाइनैमिक और सेशन के नियमों से उलट, किसी एक्सटेंशन को इंस्टॉल या अपग्रेड करने पर, स्टैटिक नियम पैकेज, इंस्टॉल, और अपडेट होते हैं. इन्हें नियम वाली फ़ाइलों में JSON फ़ॉर्मैट में सेव किया जाता है. इन्हें ऊपर बताए गए तरीके के हिसाब से, "declarative_net_request"
और "rule_resources"
कुंजियों का इस्तेमाल करके, एक्सटेंशन के तौर पर दिखाया जाता है. साथ ही, इन्हें एक या एक से ज़्यादा Ruleset
डिक्शनरी भी इस्तेमाल किया जाता है. Ruleset
डिक्शनरी में, नियम वाली फ़ाइल का पाथ, फ़ाइल में मौजूद नियमों के सेट का आईडी, और नियमसेट चालू है या बंद है. आखिरी दो नियम तब अहम होते हैं, जब प्रोग्राम के हिसाब से नियमसेट को चालू या बंद किया जाता है.
{
...
"declarative_net_request" : {
"rule_resources" : [{
"id": "ruleset_1",
"enabled": true,
"path": "rules_1.json"
},
...
]
}
...
}
नियम वाली फ़ाइलों की जांच करने के लिए, अपना एक्सटेंशन अनपैक करें. अमान्य स्टैटिक नियमों से जुड़ी गड़बड़ियां और चेतावनियां, सिर्फ़ ऐसे एक्सटेंशन के लिए दिखाई जाती हैं जिन्हें पैक नहीं किया गया है. पैक किए गए एक्सटेंशन में अमान्य स्टैटिक नियमों को अनदेखा किया जाता है.
जल्द से जल्द समीक्षा
स्टैटिक नियमसेट में होने वाले बदलावों को, जल्द से जल्द समीक्षा की मंज़ूरी मिल सकती है. यहां जाएं: ज़रूरी शर्तों को पूरा करने वाले बदलावों के लिए, जल्दी समीक्षा करने की सुविधा.
स्टैटिक नियम और नियमसेट चालू और बंद करें
अलग-अलग स्टैटिक नियम और पूरे स्टैटिक नियमसेट, दोनों को रनटाइम के दौरान चालू या बंद किया जा सकता है.
चालू स्टैटिक नियमों और रूलसेट का सेट, सभी ब्राउज़र सेशन में लागू रहता है. किसी भी एक्सटेंशन को अपडेट में लागू नहीं किया जाता, इसका मतलब है कि अपडेट के बाद, सिर्फ़ वे नियम उपलब्ध होंगे जिन्हें आपने नियम वाली फ़ाइलों में छोड़ने के लिए चुना है.
परफ़ॉर्मेंस की वजह से, एक बार में चालू किए जा सकने वाले नियमों और रूलसेट की संख्या भी सीमित होती है. लागू किए जा सकने वाले अन्य नियमों की संख्या देखने के लिए, getAvailableStaticRuleCount()
को कॉल करें. नियम की सीमाओं के बारे में जानने के लिए, नियम की सीमाएं देखें.
स्टैटिक नियमों को चालू या बंद करने के लिए, updateStaticRules()
पर कॉल करें. इस तरीके को अपनाने के लिए, UpdateStaticRulesOptions
ऑब्जेक्ट का इस्तेमाल किया जाता है. इसमें, चालू या बंद करने के लिए नियमों के आईडी वाले कलेक्शन होते हैं. आईडी, Ruleset
शब्दकोश की "id"
कुंजी का इस्तेमाल करके तय किए जाते हैं. स्टैटिक नियमों की सीमा 5,000 बंद की जा सकती है.
स्टैटिक नियमसेट चालू या बंद करने के लिए, updateEnabledRulesets()
पर कॉल करें. इस तरीके को चालू या बंद करने के लिए, UpdateRulesetOptions
ऑब्जेक्ट का इस्तेमाल किया जाता है. इसमें, नियमसेट के आईडी के कलेक्शन होते हैं. आईडी, Ruleset
शब्दकोश की "id"
कुंजी का इस्तेमाल करके तय किए जाते हैं.
नियम बनाएं
नियम चाहे किसी भी तरह का हो, नियम चार फ़ील्ड से शुरू होता है, जैसा कि नीचे दिखाया गया है. "id"
और "priority"
बटन से एक नंबर का इस्तेमाल होता है, लेकिन "action"
और "condition"
बटन से, ब्लॉक करने और रीडायरेक्ट करने से जुड़ी कई समस्याएं हो सकती हैं. यह नियम "foo.com"
से आने वाले सभी स्क्रिप्ट अनुरोधों को ब्लॉक करता है. ये अनुरोध ऐसे यूआरएल पर होते हैं जिनमें "abc"
सबस्ट्रिंग के तौर पर होता है.
{
"id" : 1,
"priority": 1,
"action" : { "type" : "block" },
"condition" : {
"urlFilter" : "abc",
"initiatorDomains" : ["foo.com"],
"resourceTypes" : ["script"]
}
}
यूआरएल का मिलान करना
डिक्लेरेटिव नेट अनुरोध की मदद से, यूआरएल को किसी पैटर्न के साथ मैच करने की सुविधा मिलती है से मेल खाने वाले सिंटैक्स या रेगुलर एक्सप्रेशन का इस्तेमाल करें.
यूआरएल फ़िल्टर सिंटैक्स
नियम की "condition"
कुंजी, बताए गए डोमेन के यूआरएल पर कार्रवाई करने के लिए, "urlFilter"
कुंजी को अनुमति देती है. पैटर्न मैचिंग टोकन का इस्तेमाल करके पैटर्न बनाए जाते हैं. यहां कुछ उदाहरण दिए गए हैं.
urlFilter |
मैच करती स्ट्रिंग | मिलान नहीं होता है |
---|---|---|
"abc" |
https://abcd.com https://example.com/abcd |
https://ab.com |
"abc*d" |
https://abcd.com https://example.com/abcxyzd |
https://abc.com |
"||a.example.com" |
https://a.example.com/ https://b.a.example.com/xyz https://a.example.company |
https://example.com/ |
"|https*" |
https://example.com | http://example.com/ http://https.com |
"example*^123|" |
https://example.com/123 http://abc.com/example?123 |
https://example.com/1234 https://abc.com/example0123 |
रेगुलर एक्सप्रेशन
शर्तों में रेगुलर एक्सप्रेशन का भी इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए,
"regexFilter"
कुंजी. इस बारे में जानने के लिए
इन शर्तों पर लागू होने वाली सीमाएं, देखें
रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम.
यूआरएल की शर्तों को अच्छी तरह से लिखना
नियमों को लिखते समय इस बात का ध्यान रखें कि वे हमेशा एक पूरे डोमेन से मेल खाते हों. या फिर, नियम ऐसी स्थितियों में भी मैच हो सकता है, जो उम्मीद के मुताबिक न हों. उदाहरण के लिए, पैटर्न मैचिंग सिंटैक्स:
google.com
,https://example.com/?param=google.com
से गलत तरीके से मेल खाता है||google.com
,https://google.company
से गलत तरीके से मेल खाता हैhttps://www.google.com
,https://example.com/?param=https://www.google.com
से गलत तरीके से मेल खाता है
इन्हें आज़माएं:
||google.com/
, जो सभी पाथ और सभी सबडोमेन से मेल खाता है.|https://www.google.com/
जो सभी पाथ से मेल खाता है और किसी सबडोमेन से नहीं.
इसी तरह, रेगुलर एक्सप्रेशन को ऐंकर करने के लिए, ^
और /
वर्णों का इस्तेमाल करें. इसके लिए
उदाहरण के लिए, ^https:\/\/www\.google\.com\/
, यहां दिए गए किसी भी पाथ से मेल खाता है
https://www.google.com.
नियम का मूल्यांकन
डीएनआर के नियमों को ब्राउज़र, नेटवर्क के अनुरोध की लाइफ़साइकल के अलग-अलग स्टेज पर लागू करता है.
अनुरोध से पहले
कोई अनुरोध किए जाने से पहले, एक्सटेंशन, मिलते-जुलते नियम के ज़रिए उसे ब्लॉक या रीडायरेक्ट कर सकता है. इसमें, स्कीम को एचटीटीपी से एचटीटीपीएस में अपग्रेड करना भी शामिल है.
हर एक्सटेंशन के लिए, ब्राउज़र मिलते-जुलते नियमों की सूची तय करता है. modifyHeaders
कार्रवाई वाले नियमों को यहां शामिल नहीं किया जाता, क्योंकि उन्हें बाद में मैनेज किया जाएगा. इसके अलावा, responseHeaders
शर्त वाले नियमों को बाद में माना जाएगा (जब रिस्पॉन्स हेडर उपलब्ध होंगे) और इन्हें शामिल नहीं किया जाता.
इसके बाद, हर एक्सटेंशन के लिए Chrome, हर अनुरोध के लिए ज़्यादा से ज़्यादा एक उम्मीदवार चुनता है. Chrome, मैचिंग के सभी नियमों को प्राथमिकता के हिसाब से क्रम में लगाकर, मिलता-जुलता नियम ढूंढता है. एक जैसी प्राथमिकता वाले नियमों को कार्रवाई (allow
या allowAllRequests
> block
> upgradeScheme
> redirect
) के हिसाब से क्रम में लगाया जाता है.
अगर उम्मीदवार allow
या allowAllRequests
नियम है या जिस फ़्रेम में अनुरोध किया जा रहा है वह इस एक्सटेंशन से ज़्यादा या बराबर प्राथमिकता वाले allowAllRequests
नियम से मेल खाता है, तो अनुरोध "अनुमति" है और अनुरोध पर एक्सटेंशन का कोई असर नहीं होगा.
अगर एक से ज़्यादा एक्सटेंशन इस अनुरोध को ब्लॉक या रीडायरेक्ट करना चाहते हैं, तो सिर्फ़ एक कार्रवाई चुनी जाती है. Chrome ऐसा करने के लिए नियमों को block
> के क्रम में लगाता है redirect
या upgradeScheme
> allow
या allowAllRequests
. अगर दो नियम एक ही तरह के हैं, तो Chrome सबसे हाल में इंस्टॉल किए गए एक्सटेंशन में से नियम चुनता है.
अनुरोध के हेडर भेजने से पहले
इससे पहले कि Chrome, सर्वर को अनुरोध के हेडर भेजे, उन्हें मेल खाने वाले modifyHeaders
नियमों के आधार पर अपडेट किया जाता है.
किसी एक एक्सटेंशन में, Chrome, मेल खाने वाले modifyHeaders
नियमों को ढूंढकर लागू करने के लिए, बदलावों की सूची बनाता है. पहले की तरह ही, इसमें सिर्फ़ ऐसे नियम शामिल किए जाते हैं जिनकी प्राथमिकता, मेल खाने वाले allow
या allowAllRequests
नियम से ज़्यादा होती है.
ये नियम Chrome द्वारा इस क्रम में लागू किए जाते हैं कि सबसे हाल ही में इंस्टॉल किए गए एक्सटेंशन के नियमों का हमेशा किसी पुराने एक्सटेंशन के नियमों से पहले मूल्यांकन किया जाता है. इसके अलावा, किसी एक एक्सटेंशन की ऊंची प्राथमिकता वाले नियम हमेशा उसी एक्सटेंशन की कम प्राथमिकता वाले नियमों से पहले लागू होते हैं. ध्यान देने वाली बात यह है कि यहां तक कि सभी एक्सटेंशन में भी:
- अगर कोई नियम किसी हेडर में जोड़ा जाता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जोड़े जा सकते हैं. सेट करने और हटाने की कार्रवाइयों की अनुमति नहीं है.
- अगर कोई नियम हेडर सेट करता है, तो उसी एक्सटेंशन के कम प्राथमिकता वाले नियम ही उस हेडर में जुड़ सकते हैं. कोई और बदलाव करने की अनुमति नहीं है.
- अगर कोई नियम हेडर को हटा देता है, तो कम प्राथमिकता वाले नियम हेडर में और बदलाव नहीं कर सकते.
जवाब मिलने के बाद
रिस्पॉन्स हेडर मिलने के बाद, Chrome responseHeaders
शर्त के साथ नियमों का आकलन करता है.
इन नियमों को action
और priority
के मुताबिक क्रम में लगाने और मेल खाने वाले allow
या allowAllRequests
नियम की वजह से गै़र-ज़रूरी नियम हटाने के बाद (यह "अनुरोध से पहले वाले चरण" के जैसा ही होता है) Chrome, किसी एक्सटेंशन के लिए अनुरोध को ब्लॉक या रीडायरेक्ट कर सकता है.
ध्यान दें कि अगर कोई अनुरोध इस चरण पर आता है, तो अनुरोध पहले ही सर्वर को भेजा जा चुका है और सर्वर को अनुरोध के मुख्य हिस्से जैसा डेटा मिल चुका है. रिस्पॉन्स हेडर की शर्त वाला ब्लॉक या रीडायरेक्ट करने वाला नियम अब भी चलेगा, लेकिन अनुरोध को ब्लॉक या रीडायरेक्ट नहीं कर सकता.
ब्लॉक करने के नियम के मामले में, इसे उस पेज से मैनेज किया जाता है जिस पर ब्लॉक किया गया जवाब मिलने का अनुरोध किया गया था और Chrome ने अनुरोध को जल्दी खत्म कर दिया. रीडायरेक्ट नियम के मामले में, Chrome रीडायरेक्ट किए गए यूआरएल के लिए एक नया अनुरोध करता है. इस बात का ध्यान रखें कि क्या ये व्यवहार, आपके एक्सटेंशन के लिए निजता से जुड़ी उम्मीदों को पूरा करते हैं.
अगर अनुरोध को ब्लॉक या रीडायरेक्ट नहीं किया जाता है, तो Chrome modifyHeaders
नियम लागू करता है. रिस्पॉन्स हेडर में बदलाव लागू करने की सुविधा, "अनुरोध के हेडर भेजने से पहले" सेक्शन में बताए गए तरीके की तरह ही काम करती है. अनुरोध के हेडर में बदलाव करने से कुछ नहीं होता, क्योंकि अनुरोध पहले ही किया जा चुका है.
सुरक्षित नियम
सुरक्षित नियमों को ऐसे नियमों के तौर पर परिभाषित किया जाता है जिनमें block
, allow
,
allowAllRequests
या upgradeScheme
. इन नियमों की वजह से
डाइनैमिक नियमों का कोटा शामिल है.
नियम की सीमाएं
ब्राउज़र में नियमों को लोड करने और उनका आकलन करने में परफ़ॉर्मेंस ओवरहेड होता है. इसलिए, एपीआई का इस्तेमाल करते समय कुछ सीमाएं लागू होती हैं. सीमाएं इस बात पर निर्भर करती हैं कि जिसका आप उपयोग कर रहे हैं.
स्टैटिक नियम
स्टैटिक नियम वे नियम होते हैं जिनके बारे में मेनिफ़ेस्ट फ़ाइल में बताया जाता है. कोई एक्सटेंशन, "rule_resources"
मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर ज़्यादा से ज़्यादा 100 स्टैटिक नियमसेट तय कर सकता है. हालांकि, एक बार में इनमें से सिर्फ़ 50 रूलसेट चालू किए जा सकते हैं. बाद वाले चरण को MAX_NUMBER_OF_ENABLED_STATIC_RULESETS
कहा जाता है. कुल मिलाकर, उन नियमों की संख्या कम से कम 30,000 नियमों की होती है. इसे GUARANTEED_MINIMUM_STATIC_RULES
कहा जाता है.
उसके बाद उपलब्ध नियमों की संख्या इस बात पर निर्भर करती है कि उपयोगकर्ता के ब्राउज़र पर इंस्टॉल किए गए सभी एक्सटेंशन के ज़रिए कितने नियम चालू किए गए हैं. getAvailableStaticRuleCount()
पर कॉल करके, रनटाइम के दौरान यह नंबर ढूंढा जा सकता है. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.
सेशन के नियम
किसी एक्सटेंशन में, ज़्यादा से ज़्यादा 5,000 सेशन नियम हो सकते हैं. यह इस तरह सामने आता है
MAX_NUMBER_OF_SESSION_RULES
.
Chrome 120 से पहले, डाइनैमिक और सेशन के नियमों को मिलाकर ज़्यादा से ज़्यादा 5,000 नियम बनाए जा सकते थे.
डाइनैमिक नियम
किसी एक्सटेंशन में कम से कम 5,000 डाइनैमिक नियम हो सकते हैं. यह इस तरह सामने आता है
MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES
.
Chrome 121 से, सुरक्षित डाइनैमिक नियमों के लिए ज़्यादा से ज़्यादा 30,000 नियम उपलब्ध हैं.
MAX_NUMBER_OF_DYNAMIC_RULES
के तौर पर दिखाया गया. कोई भी
5,000 की सीमा के अंदर जोड़े गए असुरक्षित नियमों को भी इस सीमा में गिना जाएगा.
Chrome 120 से पहले, डाइनैमिक और सेशन के नियमों की सीमा 5,000 थी.
रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम
सभी तरह के नियम रेगुलर एक्सप्रेशन का इस्तेमाल कर सकते हैं; हालांकि, हर टाइप के रेगुलर एक्सप्रेशन नियमों की कुल संख्या 1,000 से ज़्यादा नहीं हो सकती. इसे MAX_NUMBER_OF_REGEX_RULES कहा जाता है.
इसके अलावा, कंपाइल किए जाने के बाद हर नियम का साइज़ 2 केबी से कम होना चाहिए. यह मोटे तौर पर नियम की जटिलता के बारे में है. अगर किसी ऐसे नियम को लोड करने की कोशिश की जाती है जो इस सीमा से ज़्यादा है, तो आपको नीचे बताई गई चेतावनी दिखेगी और नियम को अनदेखा कर दिया जाएगा.
rules_1.json: Rule with id 1 specified a more complex regex than allowed
as part of the "regexFilter" key.
सर्विस वर्कर के साथ इंटरैक्शन
declarativeNetRequest सिर्फ़ उन अनुरोधों पर लागू होता है जो नेटवर्क स्टैक तक पहुंचते हैं. इसमें एचटीटीपी कैश मेमोरी से मिले रिस्पॉन्स शामिल हैं. हालांकि, हो सकता है कि इनमें वे रिस्पॉन्स शामिल न हों जो सर्विस वर्कर के onfetch
हैंडलर से गुज़रते हों. declarativeNetRequest ने सर्विस वर्कर के जनरेट किए गए या CacheStorage
से मिले रिस्पॉन्स पर असर नहीं पड़ेगा. हालांकि, सर्विस वर्कर में fetch()
को किए गए कॉल पर इसका असर पड़ेगा.
वेब पर ऐक्सेस किए जा सकने वाले संसाधन
declarativeNetRequest नियम, सार्वजनिक संसाधन अनुरोध से किसी ऐसे संसाधन पर रीडायरेक्ट नहीं किया जा सकता जिसे वेब ऐक्सेस न किया जा सके. ऐसा करने पर गड़बड़ी ट्रिगर हो जाती है. यह बात तब भी लागू होती है, जब बताए गए वेब ऐक्सेस करने लायक संसाधन का मालिकाना हक रीडायरेक्ट करने वाले एक्सटेंशन के पास हो. declarativeNetRequest के लिए संसाधनों का एलान करने के लिए, मेनिफ़ेस्ट की "web_accessible_resources"
कैटगरी का इस्तेमाल करना.
हेडर में बदलाव
जोड़ने की कार्रवाई सिर्फ़ इन हेडर के लिए काम करती है: accept
, accept-encoding
, accept-language
, access-control-request-headers
, cache-control
, connection
, content-language
, cookie
, forwarded
, if-match
, if-none-match
, keep-alive
, range
, te
, trailer
, transfer-encoding
, upgrade
, user-agent
, via
, want-digest
, x-forwarded-for
.
उदाहरण
कोड के उदाहरण
डाइनैमिक नियमों को अपडेट करना
नीचे दिए गए उदाहरण में, updateDynamicRules()
को कॉल करने का तरीका बताया गया है. updateSessionRules()
के लिए भी यही प्रक्रिया है.
// Get arrays containing new and old rules
const newRules = await getNewRules();
const oldRules = await chrome.declarativeNetRequest.getDynamicRules();
const oldRuleIds = oldRules.map(rule => rule.id);
// Use the arrays to update the dynamic rules
await chrome.declarativeNetRequest.updateDynamicRules({
removeRuleIds: oldRuleIds,
addRules: newRules
});
स्टैटिक नियमसेट अपडेट करें
यहां दिए गए उदाहरण में, नियमसेट को चालू और बंद करने का तरीका बताया गया है. ऐसा, उपलब्ध स्टैटिक नियमसेट की संख्या और चालू किए गए स्टैटिक नियमसेट की ज़्यादा से ज़्यादा संख्या को ध्यान में रखते हुए किया गया है. आपको ऐसा तब करना चाहिए, जब आपको स्टैटिक नियमों की संख्या, तय संख्या से ज़्यादा हो. यह काम करे, इसके लिए आपके कुछ नियमसेट इंस्टॉल होने चाहिए, जिनमें आपके कुछ नियमसेट बंद हों (मैनिफ़ेस्ट फ़ाइल में "Enabled"
को false
पर सेट किया गया है).
async function updateStaticRules(enableRulesetIds, disableCandidateIds) {
// Create the options structure for the call to updateEnabledRulesets()
let options = { enableRulesetIds: enableRulesetIds }
// Get the number of enabled static rules
const enabledStaticCount = await chrome.declarativeNetRequest.getEnabledRulesets();
// Compare rule counts to determine if anything needs to be disabled so that
// new rules can be enabled
const proposedCount = enableRulesetIds.length;
if (enabledStaticCount + proposedCount > chrome.declarativeNetRequest.MAX_NUMBER_OF_ENABLED_STATIC_RULESETS) {
options.disableRulesetIds = disableCandidateIds
}
// Update the enabled static rules
await chrome.declarativeNetRequest.updateEnabledRulesets(options);
}
नियम के उदाहरण
नीचे दिए गए उदाहरण बताते हैं कि Chrome किसी एक्सटेंशन में नियमों को कैसे प्राथमिकता देता है. इनकी समीक्षा करते समय, हो सकता है कि आप प्राथमिकता नियमों को एक अलग विंडो में खोलना चाहें.
"प्राथमिकता" बटन
इन उदाहरणों के लिए, *://*.example.com/*
के पास होस्ट की अनुमति होनी चाहिए.
किसी खास यूआरएल की प्राथमिकता जानने के लिए, (डेवलपर के तय किए गए) "priority"
बटन, "action"
बटन, और "urlFilter"
बटन को देखें. ये उदाहरण, उदाहरण के तौर पर बनाई गई नियम फ़ाइल के बारे में बताते हैं, जो उनके नीचे दिखाई गई है.
- https://google.com पर जाने के लिए नेविगेशन
- इस यूआरएल में दो नियम हैं: आईडी 1 और 4 वाले नियम. आईडी 1 वाला नियम लागू होता है, क्योंकि
"redirect"
कार्रवाइयों के मुकाबले"block"
कार्रवाइयों को ज़्यादा प्राथमिकता मिलती है. बाकी नियम लागू नहीं होते, क्योंकि वे लंबे यूआरएल के लिए होते हैं. - https://google.com/1234 पर नेविगेट करें
- ज़्यादा लंबा यूआरएल होने की वजह से, अब आईडी 2 वाला नियम, आईडी 1 और 4 वाले नियमों के साथ-साथ मेल खाता है. आईडी 2 वाला नियम लागू होता है, क्योंकि
"block"
और"redirect"
के मुकाबले"allow"
की प्राथमिकता ज़्यादा है. - https://google.com/12345 पर नेविगेट करें
- सभी चार नियम इस यूआरएल से मेल खाते हैं. आईडी 3 वाला नियम लागू होता है, क्योंकि डेवलपर की तय की गई प्राथमिकता, ग्रुप की सबसे बड़ी प्राथमिकता होती है.
[
{
"id": 1,
"priority": 1,
"action": { "type": "block" },
"condition": {"urlFilter": "||google.com/", "resourceTypes": ["main_frame"] }
},
{
"id": 2,
"priority": 1,
"action": { "type": "allow" },
"condition": { "urlFilter": "||google.com/123", "resourceTypes": ["main_frame"] }
},
{
"id": 3,
"priority": 2,
"action": { "type": "block" },
"condition": { "urlFilter": "||google.com/12345", "resourceTypes": ["main_frame"] }
},
{
"id": 4,
"priority": 1,
"action": { "type": "redirect", "redirect": { "url": "https://example.com" } },
"condition": { "urlFilter": "||google.com/", "resourceTypes": ["main_frame"] }
},
]
रीडायरेक्ट
नीचे दिए गए उदाहरण में *://*.example.com/*
के लिए होस्ट की अनुमति ज़रूरी है.
नीचे दिए गए उदाहरण में, example.com से एक्सटेंशन के अंदर ही किसी पेज पर अनुरोध को रीडायरेक्ट करने का तरीका बताया गया है. एक्सटेंशन पाथ /a.jpg
, chrome-extension://EXTENSION_ID/a.jpg
तक ले जाता है, जहां EXTENSION_ID
आपके एक्सटेंशन का आईडी है. यह काम करे, इसके लिए मेनिफ़ेस्ट को /a.jpg
को वेब को ऐक्सेस करने वाले संसाधन के तौर पर बताना चाहिए.
{
"id": 1,
"priority": 1,
"action": { "type": "redirect", "redirect": { "extensionPath": "/a.jpg" } },
"condition": {
"urlFilter": "||https://www.example.com/",
"resourceTypes": ["main_frame"]
}
}
example.com के सबडोमेन पर रीडायरेक्ट करने के लिए, "transform"
कुंजी का इस्तेमाल किया जाता है. यह example.com से किसी भी स्कीम वाले अनुरोधों को रोकने के लिए, डोमेन नेम ऐंकर ("||") का इस्तेमाल करता है. "transform"
में मौजूद "scheme"
कुंजी से यह पता चलता है कि सबडोमेन पर रीडायरेक्ट करने के लिए, हमेशा "https" का इस्तेमाल किया जाएगा.
{
"id": 1,
"priority": 1,
"action": {
"type": "redirect",
"redirect": {
"transform": { "scheme": "https", "host": "new.example.com" }
}
},
"condition": {
"urlFilter": "||example.com/",
"resourceTypes": ["main_frame"]
}
}
नीचे दिए गए उदाहरण में, रेगुलर एक्सप्रेशन का इस्तेमाल करके https://www.abc.xyz.com/path
से https://abc.xyz.com/path
पर रीडायरेक्ट किया गया है. "regexFilter"
कुंजी में देखें कि फ़ुल स्टॉप को कैसे हटाया जाता है और कैप्चर करने वाला ग्रुप, "abc" को चुनता है या "def". "regexSubstitution"
कुंजी, "\1" का इस्तेमाल करके रेगुलर एक्सप्रेशन के पहले दिखाए गए मैच के बारे में बताती है. इस मामले में, "abc" रीडायरेक्ट किए गए यूआरएल से कैप्चर करके, विकल्प में रखा जाता है.
{
"id": 1,
"priority": 1,
"action": {
"type": "redirect",
"redirect": {
"regexSubstitution": "https://\\1.xyz.com/"
}
},
"condition": {
"regexFilter": "^https://www\\.(abc|def)\\.xyz\\.com/",
"resourceTypes": [
"main_frame"
]
}
}
हेडर
नीचे दिए गए उदाहरण में मुख्य फ़्रेम और किसी भी सब-फ़्रेम, दोनों से सभी कुकी हटाई गई हैं.
{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"requestHeaders": [{ "header": "cookie", "operation": "remove" }]
},
"condition": { "resourceTypes": ["main_frame", "sub_frame"] }
}
टाइप
DomainType
इससे यह पता चलता है कि अनुरोध जिस फ़्रेम से जुड़ा है वह पहले पक्ष का है या तीसरे पक्ष का. किसी अनुरोध को पहला पक्ष तब माना जाता है, जब उसका डोमेन (eTLD+1) उसी फ़्रेम के मुताबिक होता है जिससे अनुरोध किया गया था.
Enum
"firstparty"
नेटवर्क अनुरोध उस फ़्रेम का पहला पक्ष है जिसमें यह शुरू हुआ था.
"तीसरा पक्ष"
नेटवर्क अनुरोध जिस फ़्रेम से मिला है उसका तीसरा पक्ष है.
ExtensionActionOptions
प्रॉपर्टी
-
displayActionCountAsBadgeText
बूलियन ज़रूरी नहीं
चुनें कि किसी पेज के लिए, ऐक्शन की संख्या को एक्सटेंशन के बैज टेक्स्ट के तौर पर अपने-आप दिखाना है या नहीं. यह प्राथमिकता सभी सेशन में लागू रहती है.
-
tabUpdate
TabActionCountUpdate ज़रूरी नहीं है
Chrome 89 और उसके बाद के वर्शनइस बारे में जानकारी कि टैब में की जाने वाली कार्रवाइयों की संख्या को कैसे अडजस्ट करना है.
GetDisabledRuleIdsOptions
प्रॉपर्टी
-
rulesetId
स्ट्रिंग
स्टैटिक
Ruleset
से जुड़ा आईडी.
GetRulesFilter
प्रॉपर्टी
-
ruleIds
नंबर[] ज़रूरी नहीं
अगर तय किया गया है, तो सिर्फ़ मेल खाने वाले आईडी वाले नियम शामिल किए जाते हैं.
HeaderInfo
प्रॉपर्टी
-
excludedValues
स्ट्रिंग[] ज़रूरी नहीं
अगर हेडर मौजूद है, तो यह शर्त मेल नहीं खाती. हालांकि, इसके मान में इस सूची का कम से कम एक एलिमेंट मौजूद है. यह
values
की तरह ही मैच पैटर्न सिंटैक्स का इस्तेमाल करता है. -
हेडर
स्ट्रिंग
हेडर का नाम. यह शर्त नाम से सिर्फ़ तब मैच होती है, जब
values
औरexcludedValues
दोनों के बारे में न बताया गया हो. -
मान
स्ट्रिंग[] ज़रूरी नहीं
तय किए जाने पर, यह शर्त तब मैच होती है, जब हेडर की वैल्यू इस सूची में कम से कम एक पैटर्न से मेल खाती है. यह केस-इनसेंसिटिव हेडर वैल्यू मैचिंग के साथ-साथ इन कंस्ट्रक्ट का भी इस्तेमाल करता है:
'*' : जितने चाहें उतने वर्णों से मेल खाता है.
'?' : शून्य या एक वर्ण से मेल खाता है.
'*' और '?' को बैकस्लैश से एस्केप किया जा सकता है, जैसे '\*' और '\?'
HeaderOperation
इससे "modifyHeaders" के लिए संभावित कार्रवाइयों के बारे में पता चलता है नियम.
Enum
"append"
बताए गए हेडर के लिए नई एंट्री जोड़ता है. अनुरोध के हेडर के लिए यह कार्रवाई नहीं की जा सकती.
"set"
खास हेडर के लिए नई वैल्यू सेट करता है और उसी नाम वाले किसी मौजूदा हेडर को हटाता है.
"हटाएं"
खास हेडर के लिए सभी एंट्री हटा देता है.
IsRegexSupportedResult
प्रॉपर्टी
-
isSupported
बूलियन
-
कारण
UnsupportedRegexReason ज़रूरी नहीं है
रेगुलर एक्सप्रेशन के काम न करने की वजह बताता है. सिर्फ़ तब दिया जाता है, जब
isSupported
गलत हो.
MatchedRule
प्रॉपर्टी
-
ruleId
संख्या
मिलते-जुलते नियम का आईडी.
-
rulesetId
स्ट्रिंग
उस
Ruleset
का आईडी जिससे यह नियम जुड़ा है. डाइनैमिक नियमों के सेट से शुरू होने वाले नियम के लिए, यहDYNAMIC_RULESET_ID
के बराबर होगा.
MatchedRuleInfo
प्रॉपर्टी
-
नियम
-
tabId
संख्या
अगर टैब अब भी चालू है, तो उस टैब का tabId जिससे अनुरोध शुरू हुआ था. या फिर -1.
-
timeStamp
संख्या
नियम के मेल खाने का समय. टाइमस्टैंप, समय के लिए JavaScript के तौर-तरीकों के मुताबिक होंगे. जैसे, Epoch के बाद के मिलीसेकंड की संख्या.
MatchedRuleInfoDebug
प्रॉपर्टी
-
CANNOT TRANSLATE
उस अनुरोध के बारे में जानकारी जिसके लिए नियम का मिलान किया गया था.
-
नियम
MatchedRulesFilter
प्रॉपर्टी
-
minTimeStamp
नंबर वैकल्पिक
अगर तय किया गया है, तो सिर्फ़ दिए गए टाइमस्टैंप के बाद नियमों का मिलान करता है.
-
tabId
नंबर वैकल्पिक
अगर तय किया गया है, तो सिर्फ़ दिए गए टैब के नियमों से मेल खाता है. अगर -1 पर सेट है, तो ऐसे नियमों से मेल खाता है जो किसी भी ऐक्टिव टैब से जुड़े नहीं हैं.
ModifyHeaderInfo
प्रॉपर्टी
-
हेडर
स्ट्रिंग
हेडर का नाम, जिसमें बदलाव किया जाना है.
-
कार्रवाई
हेडर पर की जाने वाली कार्रवाई.
-
value
स्ट्रिंग ज़रूरी नहीं
हेडर के लिए नई वैल्यू.
append
औरset
कार्रवाइयों के लिए बताया जाना चाहिए.
QueryKeyValue
प्रॉपर्टी
-
बटन
स्ट्रिंग
-
replaceOnly
बूलियन ज़रूरी नहीं
Chrome 94 और उसके बाद के वर्शनअगर सही है, तो क्वेरी कुंजी को सिर्फ़ तब बदला जाता है, जब वह पहले से मौजूद हो. अगर कुंजी मौजूद नहीं है, तो उसे भी जोड़ दिया जाता है. डिफ़ॉल्ट तौर पर, 'गलत' पर सेट होती है.
-
value
स्ट्रिंग
QueryTransform
प्रॉपर्टी
-
addOrReplaceParams
QueryKeyValue[] ज़रूरी नहीं
जोड़ी या बदली जाने वाली क्वेरी के-वैल्यू पेयर की सूची.
-
removeParams
स्ट्रिंग[] ज़रूरी नहीं
हटाई जाने वाली क्वेरी कुंजियों की सूची.
Redirect
प्रॉपर्टी
-
extensionPath
स्ट्रिंग ज़रूरी नहीं
एक्सटेंशन डायरेक्ट्री से जुड़ा पाथ. '/' से शुरू होना चाहिए.
-
regexSubstitution
स्ट्रिंग ज़रूरी नहीं
regexFilter
की जानकारी देने वाले नियमों के सब्सिटिट्यूशन पैटर्न. यूआरएल मेंregexFilter
का पहला मिलान इस पैटर्न से बदल दिया जाएगा.regexSubstitution
में, बैकस्लैश-एस्केप्ड डिजिट (\1 से \9) का इस्तेमाल करके, उनसे जुड़े कैप्चर ग्रुप शामिल किए जा सकते हैं. \0, मिलते-जुलते पूरे टेक्स्ट को दिखाता है. -
रूपांतरित करें
URLTransform वैकल्पिक
किए जाने वाले यूआरएल में बदलाव करना.
-
url
स्ट्रिंग ज़रूरी नहीं
दूसरा वेबलिंक. JavaScript यूआरएल पर रीडायरेक्ट करने की अनुमति नहीं है.
RegexOptions
प्रॉपर्टी
-
isCaseSensitive
बूलियन ज़रूरी नहीं
बताया गया
regex
, केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) है या नहीं. डिफ़ॉल्ट तौर पर, यह 'सही' पर सेट होती है. -
रेगुलर एक्सप्रेशन
स्ट्रिंग
जांच करने के लिए सामान्य एक्सप्रेसऑन.
-
requireCapturing
बूलियन ज़रूरी नहीं
बताई गई
regex
के लिए कैप्चर करना ज़रूरी है या नहीं. कैप्चर करने की ज़रूरत सिर्फ़ ऐसे रीडायरेक्ट नियमों के लिए होती है जिनमेंregexSubstition
कार्रवाई तय होती है. डिफ़ॉल्ट रूप से, यह वैल्यू 'गलत' पर सेट होती है.
RequestDetails
प्रॉपर्टी
-
documentId
स्ट्रिंग ज़रूरी नहीं
Chrome 106 और उसके बाद वाले वर्शनअगर यह अनुरोध किसी फ़्रेम के लिए है, तो फ़्रेम के दस्तावेज़ के लिए यूनीक आइडेंटिफ़ायर.
-
documentLifecycle
DocumentLifecycle ज़रूरी नहीं
Chrome 106 और उसके बाद वाले वर्शनअगर यह अनुरोध किसी फ़्रेम के लिए है, तो फ़्रेम के दस्तावेज़ का लाइफ़साइकल.
-
frameId
संख्या
वैल्यू 0 होने का मतलब है कि अनुरोध मुख्य फ़्रेम में हुआ है; पॉज़िटिव वैल्यू उस सबफ़्रेम के आईडी को दिखाती है जिसमें अनुरोध होता है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड होता है (
type
main_frame
याsub_frame
है), तोframeId
इस फ़्रेम के आईडी को दिखाता है, न कि आउटर फ़्रेम के आईडी को. फ़्रेम आईडी, किसी टैब में यूनीक होते हैं. -
frameType
FrameType ज़रूरी नहीं
Chrome 106 और उसके बाद वाले वर्शनअगर अनुरोध किसी फ़्रेम के लिए किया गया है, तो फ़्रेम का टाइप.
-
शुरुआत करने वाला
स्ट्रिंग ज़रूरी नहीं
वह ऑरिजिन जहां से अनुरोध किया गया था. रीडायरेक्ट के माध्यम से यह नहीं बदलता. अगर यह ओपेक ऑरिजिन है, तो स्ट्रिंग 'शून्य' का इस्तेमाल किया जाएगा.
-
तरीका
स्ट्रिंग
स्टैंडर्ड एचटीटीपी तरीका.
-
parentDocumentId
स्ट्रिंग ज़रूरी नहीं
Chrome 106 और उसके बाद वाले वर्शनअगर यह अनुरोध किसी फ़्रेम के लिए है और उसकी एक पैरंट फ़ाइल है, तो फ़्रेम के पैरंट दस्तावेज़ के लिए यूनीक आइडेंटिफ़ायर.
-
parentFrameId
संख्या
फ़्रेम का आईडी, जो अनुरोध भेजने वाले फ़्रेम को रैप करता है. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो -1 पर सेट करें.
-
requestId
स्ट्रिंग
अनुरोध का आईडी. ब्राउज़र सेशन में अनुरोध आईडी यूनीक होते हैं.
-
tabId
संख्या
उस टैब का आईडी जिसमें अनुरोध किया जाता है. अगर अनुरोध किसी टैब से न जुड़ा हो, तो उसे -1 पर सेट करें.
-
टाइप
अनुरोध का संसाधन टाइप.
-
url
स्ट्रिंग
अनुरोध का यूआरएल.
RequestMethod
यह एक नेटवर्क अनुरोध की एचटीटीपी अनुरोध के तरीके के बारे में बताता है.
Enum
"कनेक्ट करें"
"मिटाएं"
"get"
"head"
"विकल्प"
"पैच"
"पोस्ट"
"पुट"
"अन्य"
ResourceType
यह नेटवर्क अनुरोध के संसाधन प्रकार के बारे में बताता है.
Enum
"main_frame"
"sub_frame"
"स्टाइलशीट"
"script"
"इमेज"
"font"
"object"
"xmlhttprequest"
"पिंग"
"csp_report"
"मीडिया"
"websocket"
"वेबट्रांसपोर्ट"
"वेबबंडल"
"अन्य"
Rule
प्रॉपर्टी
-
ऐक्शन गेम
इस नियम के मेल खाने पर की जाने वाली कार्रवाई.
-
स्थिति
वह शर्त जिसके तहत यह नियम ट्रिगर होता है.
-
आईडी
संख्या
एक आईडी, जो किसी नियम की खास तौर पर पहचान करता है. यह ज़रूरी है और इसकी वैल्यू 1 या इससे ज़्यादा होनी चाहिए.
-
प्राथमिकता
नंबर वैकल्पिक
नियम की प्राथमिकता. डिफ़ॉल्ट तौर पर, यह वैल्यू 1 पर सेट होती है. वैल्यू तय होने पर, वैल्यू >= 1 होनी चाहिए.
RuleAction
प्रॉपर्टी
-
रीडायरेक्ट करो
रीडायरेक्ट करना ज़रूरी नहीं
रीडायरेक्ट करने का तरीका बताता है. यह सिर्फ़ रीडायरेक्ट के नियमों के लिए मान्य है.
-
requestHeaders
ModifyHeaderInfo[] वैकल्पिक
Chrome 86 और उसके बाद के वर्शनअनुरोध के लिए बदलाव करने के लिए अनुरोध हेडर. सिर्फ़ तब मान्य है, जब RuleActionType "modifyHeaders" हो.
-
responseHeaders
ModifyHeaderInfo[] वैकल्पिक
Chrome 86 और उसके बाद के वर्शनअनुरोध के लिए बदलाव करने के लिए रिस्पॉन्स हेडर. सिर्फ़ तब मान्य है, जब RuleActionType "modifyHeaders" हो.
-
टाइप
की जाने वाली कार्रवाई का टाइप.
RuleActionType
यह बताता है कि किसी RuleCondition का मिलान होने पर, किस तरह की कार्रवाई की जानी चाहिए.
Enum
"ब्लॉक करें"
नेटवर्क अनुरोध को ब्लॉक करें.
"redirect"
नेटवर्क अनुरोध को रीडायरेक्ट करें.
"allow"
नेटवर्क अनुरोध की अनुमति दें. अगर इस अनुरोध से मेल खाने वाला अनुमति वाला कोई नियम है, तो उसे बीच में नहीं रोका जाएगा.
"अपग्रेडScheme"
अगर अनुरोध http या ftp है, तो नेटवर्क अनुरोध यूआरएल की स्कीम को https में अपग्रेड करें.
"modifyHeaders"
नेटवर्क अनुरोध के अनुरोध/रिस्पॉन्स हेडर में बदलाव करें.
"allowAllRequests"
फ़्रेम अनुरोध के साथ-साथ, फ़्रेम की हैरारकी में सभी अनुरोधों को अनुमति दें.
RuleCondition
प्रॉपर्टी
-
domainType
DomainType ज़रूरी नहीं
इससे पता चलता है कि नेटवर्क का अनुरोध, उस डोमेन के लिए पहले पक्ष का है या तीसरे पक्ष का है जिससे वह शुरू हुआ था. अगर यह जानकारी शामिल नहीं की जाती है, तो सभी अनुरोध स्वीकार कर लिए जाते हैं.
-
डोमेन
स्ट्रिंग[] ज़रूरी नहीं
Chrome 101 के बाद से अब तक काम नहीं करताइसके बजाय,
initiatorDomains
का इस्तेमाल करेंयह नियम सिर्फ़
domains
की सूची से मिलने वाले नेटवर्क अनुरोधों का मिलान करेगा. -
excludedDomains
स्ट्रिंग[] ज़रूरी नहीं
Chrome 101 के बाद से अब तक काम नहीं करताइसके बजाय,
excludedInitiatorDomains
का इस्तेमाल करेंयह नियम,
excludedDomains
की सूची से मिलने वाले नेटवर्क अनुरोधों का मिलान नहीं करेगा. -
excludedInitiatorDomains
स्ट्रिंग[] ज़रूरी नहीं
Chrome 101 और उसके बाद वाले वर्शनयह नियम,
excludedInitiatorDomains
की सूची से मिलने वाले नेटवर्क अनुरोधों का मिलान नहीं करेगा. अगर सूची खाली है या हटा दी गई है, तो कोई भी डोमेन बाहर नहीं रखा जाता. इसेinitiatorDomains
के मुकाबले प्राथमिकता दी जाती है.ध्यान दें:
- "a.example.com" जैसे उप-डोमेन भी अनुमति है.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए punycode कोड में बदलने का तरीका इस्तेमाल करें.
- इसका मिलान अनुरोध शुरू करने वाले से होता है, अनुरोध यूआरएल से नहीं.
- सूची में शामिल डोमेन के सबडोमेन भी इसमें शामिल नहीं हैं.
-
excludedRequestDomains
स्ट्रिंग[] ज़रूरी नहीं
Chrome 101 और उसके बाद वाले वर्शनअगर डोमेन,
excludedRequestDomains
की सूची में से किसी डोमेन से मेल खाते हैं, तो यह नियम नेटवर्क अनुरोधों का मिलान नहीं करेगा. अगर सूची खाली है या हटा दी गई है, तो कोई भी डोमेन बाहर नहीं रखा जाता. इसेrequestDomains
के मुकाबले प्राथमिकता दी जाती है.ध्यान दें:
- "a.example.com" जैसे उप-डोमेन भी अनुमति है.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए punycode कोड में बदलने का तरीका इस्तेमाल करें.
- सूची में शामिल डोमेन के सबडोमेन भी इसमें शामिल नहीं हैं.
-
excludedRequestMethods
RequestMethod[] ज़रूरी नहीं
Chrome 91 और उसके बाद वाले वर्शन के लिएअनुरोध के उन तरीकों की सूची जिनसे नियम मैच नहीं करेगा.
requestMethods
औरexcludedRequestMethods
में से सिर्फ़ एक के बारे में बताया जाना चाहिए. अगर दोनों में से कोई भी तरीका नहीं चुना गया है, तो अनुरोध करने के सभी तरीके मेल खाते हैं. -
excludedResourceTypes
ResourceType[] ज़रूरी नहीं
ऐसे संसाधन टाइप की सूची जिनसे नियम मैच नहीं करेगा.
resourceTypes
औरexcludedResourceTypes
में से सिर्फ़ एक के बारे में बताया जाना चाहिए. अगर दोनों में से किसी का भी इस्तेमाल नहीं किया गया है, तो "main_frame" को छोड़कर, बाकी सभी तरह के संसाधन ब्लॉक किए गए हैं. -
excludedResponseHeaders
HeaderInfo[] वैकल्पिक
Chrome 128 और उसके बाद वाले वर्शनअगर अनुरोध इस सूची (अगर बताया गया है) में किसी रिस्पॉन्स हेडर की शर्त से मेल खाता है, तो नियम मेल नहीं खाएगा. अगर
excludedResponseHeaders
औरresponseHeaders
, दोनों का इस्तेमाल किया जाता है, तोexcludedResponseHeaders
प्रॉपर्टी को प्राथमिकता दी जाती है. -
excludedTabIds
नंबर[] ज़रूरी नहीं
Chrome 92 और उसके बाद वाले वर्शन के लिएtabs.Tab.id
की सूची, जिससे नियम मेल नहीं खाना चाहिए.tabs.TAB_ID_NONE
के आईडी में ऐसे अनुरोध शामिल नहीं किए जाते जो किसी टैब से नहीं आते. यह सुविधा सिर्फ़ सेशन के स्कोप वाले नियमों के लिए काम करती है. -
initiatorDomains
स्ट्रिंग[] ज़रूरी नहीं
Chrome 101 और उसके बाद वाले वर्शनयह नियम सिर्फ़
initiatorDomains
की सूची से मिलने वाले नेटवर्क अनुरोधों का मिलान करेगा. अगर इस सूची को हटा दिया जाता है, तो यह नियम सभी डोमेन के अनुरोधों पर लागू होता है. खाली सूची की अनुमति नहीं है.ध्यान दें:
- "a.example.com" जैसे उप-डोमेन भी अनुमति है.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए punycode कोड में बदलने का तरीका इस्तेमाल करें.
- इसका मिलान अनुरोध शुरू करने वाले से होता है, अनुरोध यूआरएल से नहीं.
- सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
-
isUrlFilterCaseSensitive
बूलियन ज़रूरी नहीं
urlFilter
याregexFilter
(जो भी बताया गया हो) केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) है. डिफ़ॉल्ट रूप से गलत पर सेट होती है. -
regexFilter
स्ट्रिंग ज़रूरी नहीं
रेगुलर एक्सप्रेशन, नेटवर्क अनुरोध यूआरएल से मैच करता है. यह RE2 सिंटैक्स का पालन करता है.
ध्यान दें:
urlFilter
याregexFilter
में से सिर्फ़ एक की जानकारी दी जा सकती है.ध्यान दें:
regexFilter
में सिर्फ़ ASCII वर्ण होने चाहिए. इसका मिलान ऐसे यूआरएल से किया जाता है जहां होस्ट को punycode फ़ॉर्मैट में एन्कोड किया जाता है (अंतरराष्ट्रीय डोमेन के मामले में) और बिना ASCII वाले दूसरे वर्ण, यूआरएल को utf-8 में एन्कोड करते हैं. -
requestDomains
स्ट्रिंग[] ज़रूरी नहीं
Chrome 101 और उसके बाद वाले वर्शनयह नियम नेटवर्क अनुरोधों का मिलान सिर्फ़ तब करेगा, जब डोमेन,
requestDomains
की सूची में से किसी एक डोमेन से मेल खाता हो. अगर इस सूची को हटा दिया जाता है, तो यह नियम सभी डोमेन के अनुरोधों पर लागू होता है. खाली सूची की अनुमति नहीं है.ध्यान दें:
- "a.example.com" जैसे उप-डोमेन भी अनुमति है.
- एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
- अंतरराष्ट्रीय डोमेन के लिए punycode कोड में बदलने का तरीका इस्तेमाल करें.
- सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
-
requestMethods
RequestMethod[] ज़रूरी नहीं
Chrome 91 और उसके बाद वाले वर्शन के लिएउन एचटीटीपी अनुरोध के तरीकों की सूची जिनसे नियम मेल खा सकता है. खाली सूची की अनुमति नहीं है.
ध्यान दें:
requestMethods
नियम की शर्त तय करने पर, बिना एचटीटीपी वाले अनुरोध भी शामिल नहीं किए जाएंगे, जबकिexcludedRequestMethods
तय करने से ऐसा नहीं होगा. -
resourceTypes
ResourceType[] ज़रूरी नहीं
ऐसे संसाधन टाइप की सूची जिन्हें नियम मैच कर सकता है. खाली सूची की अनुमति नहीं है.
ध्यान दें: यह
allowAllRequests
नियमों के मुताबिक होना चाहिए. इसमें सिर्फ़sub_frame
औरmain_frame
तरह के संसाधन शामिल हो सकते हैं. -
responseHeaders
HeaderInfo[] वैकल्पिक
Chrome 128 और उसके बाद वाले वर्शनअगर अनुरोध इस सूची (अगर बताई गई है) में किसी रिस्पॉन्स हेडर शर्त से मेल खाता है, तो नियम मेल खाता है.
-
tabIds
नंबर[] ज़रूरी नहीं
Chrome 92 और उसके बाद वाले वर्शन के लिएtabs.Tab.id
की सूची, जिससे नियम मेल खाना चाहिए.tabs.TAB_ID_NONE
का आईडी, उन अनुरोधों से मेल खाता है जो किसी टैब से नहीं आते. खाली सूची की अनुमति नहीं है. यह सुविधा सिर्फ़ सेशन के स्कोप वाले नियमों के लिए काम करती है. -
urlFilter
स्ट्रिंग ज़रूरी नहीं
वह पैटर्न जिसका मिलान नेटवर्क अनुरोध के यूआरएल से किया जाता है. काम करने वाले कंस्ट्रक्ट:
'*' : वाइल्डकार्ड: जितने चाहें उतने वर्णों से मेल खाता है.
'|' : बायां/दायां ऐंकर: अगर पैटर्न के आखिर में इस्तेमाल किया जाता है, तो यूआरएल के शुरू/आखिर में इस्तेमाल किया जाता है.
'||' : डोमेन नेम का ऐंकर: अगर पैटर्न की शुरुआत में इस्तेमाल किया जाता है, तो यूआरएल के (सब-) डोमेन की शुरुआत के बारे में बताता है.
'^' : सेपरेटर वर्ण: यह किसी अक्षर, अंक या इनमें से किसी एक को छोड़कर, किसी भी चीज़ से मिलान करता है:
_
,-
,.
या%
. यह यूआरएल के आखिरी हिस्से से भी मेल खाता है.इसलिए,
urlFilter
में ये हिस्से शामिल हैं: (लेफ़्ट/डोमेन नेम ऐंकर) + पैटर्न + (राइट ऐंकर ज़रूरी नहीं है).अगर छोड़ा जाता है, तो सभी यूआरएल मेल खाते हैं. खाली स्ट्रिंग का इस्तेमाल नहीं किया जा सकता.
||*
से शुरू होने वाले पैटर्न की अनुमति नहीं है. इसके बजाय,*
का इस्तेमाल करें.ध्यान दें:
urlFilter
याregexFilter
में से सिर्फ़ एक की जानकारी दी जा सकती है.ध्यान दें:
urlFilter
में सिर्फ़ ASCII वर्ण होने चाहिए. इसका मिलान ऐसे यूआरएल से किया जाता है जहां होस्ट को punycode फ़ॉर्मैट में एन्कोड किया जाता है (अंतरराष्ट्रीय डोमेन के मामले में) और बिना ASCII वाले दूसरे वर्ण, यूआरएल को utf-8 में एन्कोड करते हैं. उदाहरण के लिए, जब अनुरोध करने के लिए यूआरएल http://abc.टेरफ़ो?क्यू=एफ़एम है, तोurlFilter
का मिलान http://abc.xn--p1ai/?q=%D1%84 यूआरएल से किया जाएगा.
Ruleset
प्रॉपर्टी
-
चालू किया गया
बूलियन
नियमसेट डिफ़ॉल्ट रूप से चालू है या नहीं.
-
आईडी
स्ट्रिंग
एक ऐसी स्ट्रिंग जो खाली नहीं है, खास तौर पर नियमों के सेट की पहचान करती है. '_' से शुरू होने वाले आईडी आंतरिक उपयोग के लिए आरक्षित हैं.
-
पाथ
स्ट्रिंग
एक्सटेंशन डायरेक्ट्री से जुड़े JSON नियमों का पाथ.
RulesMatchedDetails
प्रॉपर्टी
-
rulesMatchedInfo
दिए गए फ़िल्टर से मेल खाने वाले नियम.
TabActionCountUpdate
प्रॉपर्टी
-
अधिक
संख्या
टैब की कार्रवाई की संख्या को बढ़ाना है. नेगेटिव वैल्यू से संख्या में कमी आएगी.
-
tabId
संख्या
वह टैब जिसके लिए कार्रवाई की संख्या को अपडेट करना है.
TestMatchOutcomeResult
प्रॉपर्टी
-
matchedRules
अगर कोई नियम है, तो वह काल्पनिक अनुरोध से मेल खाता है.
TestMatchRequestDetails
प्रॉपर्टी
-
शुरुआत करने वाला
स्ट्रिंग ज़रूरी नहीं
काल्पनिक अनुरोध के लिए, शुरुआत करने वाला यूआरएल (अगर कोई है).
-
तरीका
RequestMethod ज़रूरी नहीं
काल्पनिक अनुरोध का स्टैंडर्ड एचटीटीपी तरीका. डिफ़ॉल्ट रूप से "पाएं" होता है एचटीटीपी अनुरोधों के लिए और बिना एचटीटीपी वाले अनुरोधों के लिए अनदेखा कर दिया जाता है.
-
responseHeaders
ऑब्जेक्ट ज़रूरी नहीं
मंज़ूरी बाकी हैअगर अनुरोध भेजने से पहले ब्लॉक या रीडायरेक्ट नहीं किया जाता है, तो एक काल्पनिक जवाब से दिए गए हेडर. इसे ऐसे ऑब्जेक्ट के तौर पर दिखाया जाता है जो हेडर के नाम को स्ट्रिंग की वैल्यू की सूची पर मैप करता है. अगर तय नहीं किया गया है, तो काल्पनिक रिस्पॉन्स, खाली रिस्पॉन्स हेडर दिखाएगा. इससे उन नियमों को मैच किया जा सकता है जो हेडर के मौजूद न होने से मैच करते हैं. उदा.
{"content-type": ["text/html; charset=utf-8", "multipart/form-data"]}
-
tabId
नंबर वैकल्पिक
उस टैब का आईडी जिसमें काल्पनिक अनुरोध किया जाता है. किसी असली टैब आईडी से मेल खाना ज़रूरी नहीं है. डिफ़ॉल्ट वैल्यू -1 होती है. इसका मतलब है कि अनुरोध किसी टैब से जुड़ा हुआ नहीं है.
-
टाइप
काल्पनिक अनुरोध का संसाधन टाइप.
-
url
स्ट्रिंग
काल्पनिक अनुरोध का यूआरएल.
UnsupportedRegexReason
किसी रेगुलर एक्सप्रेशन के काम न करने की वजह बताता है.
Enum
"syntaxError"
रेगुलर एक्सप्रेशन के वाक्य गलत हैं या वह ऐसी सुविधाओं का इस्तेमाल करता है जो RE2 सिंटैक्स में उपलब्ध नहीं हैं.
"memoryLimitExceeded"
रेगुलर एक्सप्रेशन मेमोरी सीमा से ज़्यादा हो गया है.
UpdateRuleOptions
प्रॉपर्टी
-
addRules
नियम[] ज़रूरी नहीं
जोड़े जाने वाले नियम.
-
removeRuleIds
नंबर[] ज़रूरी नहीं
हटाए जाने वाले नियमों के आईडी. किसी भी अमान्य आईडी को अनदेखा कर दिया जाएगा.
UpdateRulesetOptions
प्रॉपर्टी
UpdateStaticRulesOptions
प्रॉपर्टी
URLTransform
प्रॉपर्टी
-
फ़्रैगमेंट
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया हिस्सा. या तो खाली होना चाहिए, इस स्थिति में मौजूदा फ़्रैगमेंट हटा दिया जाता है; या '#' से शुरू होना चाहिए.
-
होस्ट
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया होस्ट.
-
पासवर्ड
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया पासवर्ड.
-
पाथ
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया पाथ. अगर खाली है, तो मौजूदा पाथ हटा दिया जाता है.
-
पोर्ट
स्ट्रिंग ज़रूरी नहीं
अनुरोध करने के लिए नया पोर्ट. अगर पोर्ट खाली है, तो मौजूदा पोर्ट हटा दिया जाता है.
-
क्वेरी
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नई क्वेरी. या तो खाली होना चाहिए, इस स्थिति में मौजूदा क्वेरी हटा दी जाती है; या '?' से शुरू होना चाहिए.
-
queryTransform
QueryTransform ज़रूरी नहीं
क्वेरी के की-वैल्यू पेयर को जोड़ें, हटाएं या बदलें.
-
स्कीम
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नई स्कीम. "http", "https", "ftp" वैल्यू ही डाली जा सकती हैं और "chrome-एक्सटेंशन" में से किसी एक को चुनें.
-
उपयोगकर्ता नाम
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया उपयोगकर्ता नाम.
प्रॉपर्टी
DYNAMIC_RULESET_ID
एक्सटेंशन की मदद से जोड़े गए डाइनैमिक नियमों के लिए, रूलसेट आईडी.
मान
"_डाइनैमिक"
GETMATCHEDRULES_QUOTA_INTERVAL
MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL getMatchedRules
कॉल करने के लिए दिया गया टाइम इंटरवल, मिनट में. अन्य कॉल तुरंत पूरे नहीं हो पाएंगे और runtime.lastError
सेट कर दिया जाएगा. ध्यान दें: उपयोगकर्ता के जेस्चर से जुड़े getMatchedRules
कॉल को कोटा से छूट दी गई है.
मान
10
GUARANTEED_MINIMUM_STATIC_RULES
लागू किए गए स्टैटिक नियमों की कम से कम संख्या, जिनके लिए किसी एक्सटेंशन की गारंटी दी जाती है. इस सीमा से ज़्यादा नियम होने पर, उनकी गिनती ग्लोबल स्टैटिक नियम सीमा में की जाएगी.
मान
30,000
MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL
GETMATCHEDRULES_QUOTA_INTERVAL
के दौरान getMatchedRules
को कितनी बार कॉल किया जा सकता है.
मान
20
MAX_NUMBER_OF_DYNAMIC_RULES
किसी एक्सटेंशन के ज़रिए जोड़े जा सकने वाले डाइनैमिक नियमों की ज़्यादा से ज़्यादा संख्या.
मान
30,000
MAX_NUMBER_OF_ENABLED_STATIC_RULESETS
स्टैटिक Rulesets
की ज़्यादा से ज़्यादा संख्या, जिसे कोई एक्सटेंशन एक बार में चालू कर सकता है.
मान
50
MAX_NUMBER_OF_REGEX_RULES
रेगुलर एक्सप्रेशन के ऐसे नियमों की ज़्यादा से ज़्यादा संख्या जिन्हें कोई एक्सटेंशन जोड़ सकता है. इस सीमा का आकलन, डाइनैमिक नियमों के सेट और नियम के संसाधन की फ़ाइल में बताए गए नियमों के सेट के लिए अलग से किया जाता है.
मान
1,000
MAX_NUMBER_OF_SESSION_RULES
सेशन के स्कोप वाले ऐसे नियमों की ज़्यादा से ज़्यादा संख्या जिन्हें एक्सटेंशन जोड़ सकता है.
मान
5,000
MAX_NUMBER_OF_STATIC_RULESETS
स्टैटिक Rulesets
की ज़्यादा से ज़्यादा संख्या, जिसे कोई एक्सटेंशन, "rule_resources"
मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर तय कर सकता है.
मान
100
MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES
"असुरक्षित" की ज़्यादा से ज़्यादा संख्या ऐसे डायनामिक नियम हैं, जिन्हें कोई एक्सटेंशन जोड़ सकता है.
मान
5,000
MAX_NUMBER_OF_UNSAFE_SESSION_RULES
"असुरक्षित" की ज़्यादा से ज़्यादा संख्या सेशन के स्कोप वाले ऐसे नियम जिन्हें एक्सटेंशन जोड़ सकता है.
मान
5,000
SESSION_RULESET_ID
सेशन के स्कोप वाले उन नियमों के लिए रूलसेट आईडी जिन्हें एक्सटेंशन ने जोड़ा है.
मान
"_session"
तरीके
getAvailableStaticRuleCount()
chrome.declarativeNetRequest.getAvailableStaticRuleCount(
callback?: function,
)
यह फ़ंक्शन ऐसे स्टैटिक नियमों की संख्या दिखाता है जिन्हें ग्लोबल स्टैटिक नियम सीमा पूरी होने से पहले, किसी एक्सटेंशन को चालू किया जा सकता है.
पैरामीटर
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(count: number) => void
-
सोलर पैनलों की संख्या
संख्या
-
रिटर्न
-
Promise<number>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
getDisabledRuleIds()
chrome.declarativeNetRequest.getDisabledRuleIds(
options: GetDisabledRuleIdsOptions,
callback?: function,
)
यह विकल्प, दिए गए Ruleset
में उन स्टैटिक नियमों की सूची दिखाता है जो फ़िलहाल बंद हैं.
पैरामीटर
-
विकल्प
क्वेरी के लिए नियमसेट के बारे में बताता है.
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(disabledRuleIds: number[]) => void
-
disabledRuleIds
नंबर[]
-
रिटर्न
-
प्रॉमिस<number[]>
मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
getDynamicRules()
chrome.declarativeNetRequest.getDynamicRules(
filter?: GetRulesFilter,
callback?: function,
)
यह विकल्प, एक्सटेंशन के लिए डाइनैमिक नियमों के मौजूदा सेट की जानकारी देता है. कॉलर, filter
की जानकारी देकर, फ़ेच किए गए नियमों की सूची को फ़िल्टर कर सकते हैं.
पैरामीटर
-
फ़िल्टर करें
GetRulesFilter ज़रूरी नहीं
Chrome 111 और उसके बाद वाले वर्शन के लिएफ़ेच किए गए नियमों की सूची को फ़िल्टर करने के लिए एक ऑब्जेक्ट.
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(rules: Rule[]) => void
-
नियम
नियम[]
-
रिटर्न
-
वादा<नियम[]>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
getEnabledRulesets()
chrome.declarativeNetRequest.getEnabledRulesets(
callback?: function,
)
चालू किए गए स्टैटिक नियमसेट के मौजूदा सेट के लिए आईडी दिखाता है.
पैरामीटर
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(rulesetIds: string[]) => void
-
rulesetIds
स्ट्रिंग[]
-
रिटर्न
-
Promise<string[]>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
getMatchedRules()
chrome.declarativeNetRequest.getMatchedRules(
filter?: MatchedRulesFilter,
callback?: function,
)
एक्सटेंशन से मेल खाने वाले सभी नियमों को दिखाता है. कॉलर, filter
तय करके, मेल खाने वाले नियमों की सूची को फ़िल्टर कर सकते हैं. हालांकि, ऐसा करना ज़रूरी नहीं है. यह तरीका सिर्फ़ उन एक्सटेंशन के लिए उपलब्ध है जिनके पास "declarativeNetRequestFeedback"
या filter
में बताए गए tabId
के लिए "activeTab"
की अनुमति है. ध्यान दें: ऐसे नियम जो किसी चालू दस्तावेज़ से जुड़े नहीं हैं और जिनका मिलान पांच मिनट से ज़्यादा समय पहले हुआ है उन्हें लौटाया नहीं जाएगा.
पैरामीटर
-
फ़िल्टर करें
MatchedRulesFilter ज़रूरी नहीं
मैच होने वाले नियमों की सूची को फ़िल्टर करने के लिए एक ऑब्जेक्ट.
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(details: RulesMatchedDetails) => void
-
विवरण
-
रिटर्न
-
Promise<RulesMatchedDetails>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
getSessionRules()
chrome.declarativeNetRequest.getSessionRules(
filter?: GetRulesFilter,
callback?: function,
)
यह एक्सटेंशन के लिए, सेशन के स्कोप वाले नियमों का मौजूदा सेट दिखाता है. कॉलर, filter
की जानकारी देकर, फ़ेच किए गए नियमों की सूची को फ़िल्टर कर सकते हैं.
पैरामीटर
-
फ़िल्टर करें
GetRulesFilter ज़रूरी नहीं
Chrome 111 और उसके बाद वाले वर्शन के लिएफ़ेच किए गए नियमों की सूची को फ़िल्टर करने के लिए एक ऑब्जेक्ट.
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(rules: Rule[]) => void
-
नियम
नियम[]
-
रिटर्न
-
वादा<नियम[]>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
isRegexSupported()
chrome.declarativeNetRequest.isRegexSupported(
regexOptions: RegexOptions,
callback?: function,
)
यह जांचता है कि दिया गया रेगुलर एक्सप्रेशन, regexFilter
नियम की शर्त के तौर पर काम करेगा.
पैरामीटर
-
regexOptions
जांचा जाने वाला रेगुलर एक्सप्रेशन.
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(result: IsRegexSupportedResult) => void
-
नतीजा
-
रिटर्न
-
Promise<IsRegexSupportedResult>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
setExtensionActionOptions()
chrome.declarativeNetRequest.setExtensionActionOptions(
options: ExtensionActionOptions,
callback?: function,
)
इस नीति से यह कॉन्फ़िगर किया जाता है कि टैब के लिए कार्रवाई की संख्या को एक्सटेंशन कार्रवाई के बैज टेक्स्ट के रूप में दिखाया जाना चाहिए या नहीं. साथ ही, इस नीति से उस कार्रवाई की संख्या को बढ़ाने का तरीका भी मिलता है.
पैरामीटर
-
विकल्प
-
कॉलबैक
फ़ंक्शन वैकल्पिक
Chrome 89 और उसके बाद के वर्शनcallback
पैरामीटर ऐसा दिखता है:() => void
रिटर्न
-
प्रॉमिस<void>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
testMatchOutcome()
chrome.declarativeNetRequest.testMatchOutcome(
request: TestMatchRequestDetails,
callback?: function,
)
यह जांच करता है कि एक्सटेंशन का कोई भी declarativeNetRequest नियम, किसी काल्पनिक अनुरोध से मैच करेगा या नहीं. ध्यान दें: यह सिर्फ़ ऐसे एक्सटेंशन के लिए उपलब्ध है जो पैक नहीं हैं, क्योंकि इसका इस्तेमाल सिर्फ़ एक्सटेंशन डेवलपमेंट के दौरान किया जाता है.
पैरामीटर
-
CANNOT TRANSLATE
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:(result: TestMatchOutcomeResult) => void
-
नतीजा
-
रिटर्न
-
Promise<TestMatchOutcomeResult>
मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
updateDynamicRules()
chrome.declarativeNetRequest.updateDynamicRules(
options: UpdateRuleOptions,
callback?: function,
)
यह एक्सटेंशन के लिए, डाइनैमिक नियमों के मौजूदा सेट में बदलाव करता है. सबसे पहले options.removeRuleIds
में दिए गए आईडी वाले नियमों को हटाया जाता है. इसके बाद, options.addRules
में दिए गए नियम जोड़े जाते हैं. ध्यान दें:
- यह अपडेट एक ऐटमिक ऑपरेशन के तौर पर होता है: या तो सभी तय नियम जोड़े और हटा दिए जाते हैं या फिर कोई गड़बड़ी मिलती है.
- ये नियम, सभी ब्राउज़र सेशन और एक्सटेंशन अपडेट में लागू रहते हैं.
- एक्सटेंशन पैकेज के हिस्से के तौर पर बताए गए स्टैटिक नियमों को इस फ़ंक्शन का इस्तेमाल करके हटाया नहीं जा सकता.
MAX_NUMBER_OF_DYNAMIC_RULES
किसी एक्सटेंशन के ज़रिए जोड़े जा सकने वाले डाइनैमिक नियमों की ज़्यादा से ज़्यादा संख्या होती है. असुरक्षित नियमों की संख्याMAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES
से ज़्यादा नहीं होनी चाहिए.
पैरामीटर
-
विकल्पChrome 87+
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
रिटर्न
-
प्रॉमिस<void>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
updateEnabledRulesets()
chrome.declarativeNetRequest.updateEnabledRulesets(
options: UpdateRulesetOptions,
callback?: function,
)
एक्सटेंशन के लिए चालू स्टैटिक नियमसेट के सेट को अपडेट करता है. सबसे पहले options.disableRulesetIds
में लिस्ट किए गए आईडी वाले रूलसेट जोड़े जाते हैं. इसके बाद, options.enableRulesetIds
में लिस्ट किए गए रूलसेट जोड़े जाते हैं.
ध्यान दें कि चालू स्टैटिक नियमसेट का सेट सभी सेशन में लागू रहता है, लेकिन एक्सटेंशन अपडेट में नहीं. इसका मतलब है कि rule_resources
मेनिफ़ेस्ट कुंजी, एक्सटेंशन के हर अपडेट पर चालू स्टैटिक नियमसेट के सेट को तय करेगी.
पैरामीटर
-
विकल्पChrome 87+
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
रिटर्न
-
प्रॉमिस<void>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
updateSessionRules()
chrome.declarativeNetRequest.updateSessionRules(
options: UpdateRuleOptions,
callback?: function,
)
एक्सटेंशन के लिए, सेशन के दायरे वाले नियमों के मौजूदा सेट में बदलाव करता है. सबसे पहले options.removeRuleIds
में दिए गए आईडी वाले नियमों को हटाया जाता है. इसके बाद, options.addRules
में दिए गए नियम जोड़े जाते हैं. ध्यान दें:
- यह अपडेट एक ऐटमिक ऑपरेशन के तौर पर होता है: या तो सभी तय नियम जोड़े और हटा दिए जाते हैं या फिर कोई गड़बड़ी मिलती है.
- ये नियम सभी सेशन में लागू नहीं होते और मेमोरी में इनका इस्तेमाल किया जाता है.
MAX_NUMBER_OF_SESSION_RULES
से पता चलता है कि कोई एक्सटेंशन, ज़्यादा से ज़्यादा कितने सेशन नियम जोड़ सकता है.
पैरामीटर
-
विकल्प
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
रिटर्न
-
प्रॉमिस<void>
Chrome 91 और उसके बाद वाले वर्शन के लिएमेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
updateStaticRules()
chrome.declarativeNetRequest.updateStaticRules(
options: UpdateStaticRulesOptions,
callback?: function,
)
यह Ruleset
में, अलग-अलग स्टैटिक नियमों को बंद और चालू करता है. बंद किए गए Ruleset
से जुड़े नियमों में किए गए बदलाव, अगली बार चालू होने पर लागू होंगे.
पैरामीटर
-
विकल्प
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
रिटर्न
-
प्रॉमिस<void>
मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, कॉलबैक की सुविधा इन मामलों में दी जाती है पुराने सिस्टम के साथ काम करने की सुविधा. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. कॉन्टेंट बनाने प्रॉमिस उसी टाइप के साथ ठीक होता है जिसे कॉलबैक में पास किया जाता है.
इवेंट
onRuleMatchedDebug
chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(
callback: function,
)
यह तब ट्रिगर होता है, जब किसी नियम का अनुरोध से मैच होता है. यह सिर्फ़ ऐसे एक्सटेंशन के लिए उपलब्ध है जिन्हें पैक नहीं किया गया है और जिनके पास "declarativeNetRequestFeedback"
की अनुमति है. ऐसा इसलिए, क्योंकि इसे सिर्फ़ डीबग करने के लिए इस्तेमाल किया जाता है.
पैरामीटर
-
कॉलबैक
फ़ंक्शन
callback
पैरामीटर ऐसा दिखता है:(info: MatchedRuleInfoDebug) => void
-
जानकारी
-