कंपनी का ब्यौरा
chrome.declarativeNetRequest
एपीआई का इस्तेमाल, नेटवर्क के अनुरोधों को ब्लॉक करने या उनमें बदलाव करने के लिए किया जाता है. ऐसा, डिक्लेरेटिव टोन वाले नियमों के बारे में बताकर किया जाता है. इसकी मदद से, एक्सटेंशन नेटवर्क के अनुरोधों में बदलाव किए बिना, उनका कॉन्टेंट देखे बिना और नेटवर्क के अनुरोधों में बदलाव कर सकते हैं. इस तरह, एक्सटेंशन की निजता बनाए रखने में मदद मिलती है.
अनुमतियां
declarativeNetRequest
declarativeNetRequestWithHostAccess
declarativeNetRequestFeedback
host_permissions
उपलब्धता
मेनिफ़ेस्ट
ऊपर बताई गई अनुमतियों के अलावा, कुछ खास तरह के नियमसेट, खास तौर पर स्टैटिक नियमसेट के लिए, "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"
कुंजी का इस्तेमाल करके तय किए जाते हैं.
स्टैटिक rulesets चालू या बंद करने के लिए, 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"]
}
}
urlFilter मेल खाने वाला वर्ण
नियम की "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://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 |
नियम की प्राथमिकता
वेब पेजों से भेजे गए अनुरोधों से नियम ट्रिगर होते हैं. अगर किसी खास अनुरोध से कई नियम मेल खाते हैं, तो नियमों को प्राथमिकता देनी होगी. इस सेक्शन में बताया गया है कि इन कैंपेन को किस आधार पर प्राथमिकता दी जाती है. प्राथमिकता दो चरणों में पूरी होती है.
- किसी एक्सटेंशन में मौजूद नियमों के लिए प्राथमिकता तय की जाती है.
- अगर एक से ज़्यादा एक्सटेंशन किसी अनुरोध पर एक नियम लागू कर सकते हैं, तो किसी खास अनुरोध से मेल खाने वाले सभी एक्सटेंशन के लिए प्राथमिकता तय की जाती है.
इस तरीके से मैच करने पर: किसी खास एक्सटेंशन के लिए तय किए गए किसी भी नियम को दूसरे एक्सटेंशन के नियमों के मुकाबले प्राथमिकता दी जाएगी.
किसी एक्सटेंशन में नियम की प्राथमिकता
किसी एक एक्सटेंशन में, नीचे दी गई प्रक्रिया का इस्तेमाल करके प्राथमिकता तय करने पर काम किया जाता है:
- डेवलपर की तय की गई सबसे ज़्यादा प्राथमिकता वाला नियम (दूसरे शब्दों में,
"priority"
फ़ील्ड) दिया जाता है. अगर डेवलपर की तय की गई प्राथमिकता वाले एक से ज़्यादा नियम हैं, तो
"action"
फ़ील्ड का इस्तेमाल करके नियमों को इस क्रम में प्राथमिकता दी जाती है:allow
allowAllRequests
block
upgradeScheme
redirect
अगर कार्रवाई का टाइप
block
याredirect
नहीं है, तो मेल खाने वालेmodifyHeaders
नियमों का आकलन किया जाता है. ध्यान रखें कि अगर ऐसे कोई नियम हैं जिनकी डेवलपर ने प्राथमिकता तय की है औरallow
औरallowAllRequests
के लिए तय की गई प्राथमिकता से कम है, तो ऐसे नियमों को अनदेखा किया जाता है.अगर कई नियम एक ही हेडर में बदलाव करते हैं, तो बदलाव को डेवलपर के बनाए गए
"priority"
फ़ील्ड और बताई गई कार्रवाइयों से तय किया जाता है.- अगर कोई नियम किसी हेडर में जोड़ा जाता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जोड़े जा सकते हैं. सेट करने और हटाने की कार्रवाइयों की अनुमति नहीं है.
- अगर कोई नियम हेडर सेट करता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जोड़े जा सकते हैं. कोई और बदलाव करने की अनुमति नहीं है.
- अगर कोई नियम हेडर को हटा देता है, तो कम प्राथमिकता वाले नियम हेडर में और बदलाव नहीं कर सकते.
एक्सटेंशन के बीच नियम की प्राथमिकता
अगर सिर्फ़ एक एक्सटेंशन में कोई ऐसा नियम है जो किसी अनुरोध से मेल खाता है, तो वह नियम लागू होता है. हालांकि, अगर एक से ज़्यादा एक्सटेंशन किसी अनुरोध से मैच करते हैं, तो इस प्रोसेस का इस्तेमाल किया जाता है:
नियमों को
"action"
फ़ील्ड का इस्तेमाल करके, नीचे दिए गए क्रम में प्राथमिकता दी जाती है:block
redirect
याupgradeScheme
allow
याallowAllRequests
अगर एक से ज़्यादा नियम मेल खाते हैं, तो सबसे हाल ही में इंस्टॉल किए गए एक्सटेंशन को प्राथमिकता दी जाती है.
नियम की सीमाएं
ब्राउज़र में नियमों को लोड करने और उनका आकलन करने पर, परफ़ॉर्मेंस पर असर पड़ता है. इसलिए, एपीआई का इस्तेमाल करते समय कुछ सीमाएं लागू होती हैं. सीमाएं इस बात पर निर्भर करती हैं कि आपने किस तरह के नियम का इस्तेमाल किया है.
स्टैटिक नियम
स्टैटिक नियम वे नियम होते हैं जिनके बारे में मेनिफ़ेस्ट फ़ाइल में बताया जाता है. कोई एक्सटेंशन, "rule_resources"
मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर ज़्यादा से ज़्यादा 50 स्टैटिक rulesets तय कर सकता है, लेकिन एक बार में इनमें से सिर्फ़ 10 रूलसेट चालू किए जा सकते हैं. बाद वाले चरण को MAX_NUMBER_OF_ENABLED_STATIC_RULESETS
कहा जाता है. कुल मिलाकर, उन नियमों की संख्या कम से कम 30,000 नियमों की होती है. इसे GUARANTEED_MINIMUM_STATIC_RULES
कहा जाता है.
उसके बाद उपलब्ध नियमों की संख्या इस बात पर निर्भर करती है कि उपयोगकर्ता के ब्राउज़र पर इंस्टॉल किए गए सभी एक्सटेंशन के ज़रिए कितने नियम चालू किए गए हैं. getAvailableStaticRuleCount()
पर कॉल करके, रनटाइम के दौरान यह नंबर ढूंढा जा सकता है. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.
डाइनैमिक और सेशन के नियम
डाइनैमिक और सेशन के नियमों पर लागू होने वाली सीमाएं, स्टैटिक नियमों से आसान होती हैं. दोनों की कुल संख्या 5000 से ज़्यादा नहीं हो सकती. इसे MAX_NUMBER_OF_DYNAMIC_AND_SESSION_RULES
कहा जाता है.
रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम
सभी तरह के नियम रेगुलर एक्सप्रेशन का इस्तेमाल कर सकते हैं. हालांकि, हर तरह के रेगुलर एक्सप्रेशन नियमों की कुल संख्या 1,000 से ज़्यादा नहीं हो सकती. इसे MAX_NUMBER_OF_REGEX_RULES कहा जाता है.
इसके अलावा, कंपाइल किए जाने के बाद हर नियम का साइज़ 2 केबी से कम होना चाहिए. यह मोटे तौर पर नियम की जटिलता के बारे में है. अगर कोई ऐसा नियम लोड करने की कोशिश की जाती है जो इस सीमा को पार कर जाता है, तो आपको नीचे दिए गए नियम जैसी एक चेतावनी दिखेगी और नियम को अनदेखा कर दिया जाएगा.
rules_1.json: Rule with id 1 specified a more complext regex than allowed
as part of the "regexFilter" key.
सर्विस वर्कर के साथ इंटरैक्शन
declarativeNetRequest सिर्फ़ उन अनुरोधों पर लागू होता है जो नेटवर्क स्टैक तक पहुंचते हैं. इसमें एचटीटीपी कैश मेमोरी से मिले रिस्पॉन्स शामिल हैं, लेकिन हो सकता है कि इनमें सर्विस वर्कर के onfetch
हैंडलर से मिलने वाले रिस्पॉन्स शामिल न हों. declarativeNetRequest से सर्विस वर्कर से जनरेट होने वाले या CacheStorage
से मिले जवाबों पर असर डालने वाली सेटिंग, लेकिन सर्विस वर्कर में किए गए fetch()
को किए गए कॉल पर असर पड़ेगा.
वेब पर ऐक्सेस किए जा सकने वाले संसाधन
declarativeNetRequest नियम, सार्वजनिक संसाधन अनुरोध से किसी ऐसे संसाधन पर रीडायरेक्ट नहीं किया जा सकता जिसे वेब ऐक्सेस न किया जा सके. ऐसा करने पर गड़बड़ी ट्रिगर हो जाती है. यह बात तब भी लागू होती है, जब बताए गए वेब ऐक्सेस करने लायक संसाधन का मालिकाना हक रीडायरेक्ट करने वाले एक्सटेंशन के पास हो. declarativeNetRequest के लिए संसाधनों का एलान करने के लिए, मेनिफ़ेस्ट की "web_accessible_resources"
कैटगरी का इस्तेमाल करना.
उदाहरण
कोड के उदाहरण
डाइनैमिक नियमों को अपडेट करना
नीचे दिए गए उदाहरण में, 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
नंबर[] ज़रूरी नहीं
अगर तय किया गया है, तो सिर्फ़ मेल खाने वाले आईडी वाले नियम शामिल किए जाते हैं.
HeaderOperation
इससे "modifyHeaders" नियम के लिए संभावित कार्रवाइयों के बारे में पता चलता है.
Enum
"append"
बताए गए हेडर के लिए नई एंट्री जोड़ता है. अनुरोध के हेडर के लिए यह कार्रवाई नहीं की जा सकती.
"set"
खास हेडर के लिए नई वैल्यू सेट करता है और उसी नाम वाले किसी मौजूदा हेडर को हटाता है.
"हटाएं"
खास हेडर के लिए सभी एंट्री हटा देता है.
IsRegexSupportedResult
प्रॉपर्टी
-
isSupported
boolean
-
कारण
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 वैकल्पिक
किए जाने वाले यूआरएल में बदलाव करना.
-
यूआरएल
स्ट्रिंग ज़रूरी नहीं
दूसरा वेबलिंक. 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 और उसके बाद के वर्शनअगर अनुरोध किसी फ़्रेम के लिए किया गया है, तो फ़्रेम का टाइप.
-
शुरुआत करने वाला
स्ट्रिंग ज़रूरी नहीं
वह ऑरिजिन जहां से अनुरोध किया गया था. रीडायरेक्ट के माध्यम से यह नहीं बदलता. अगर यह ओपेक ऑरिजिन है, तो 'शून्य' स्ट्रिंग का इस्तेमाल किया जाएगा.
-
method
स्ट्रिंग
स्टैंडर्ड एचटीटीपी तरीका.
-
parentDocumentId
स्ट्रिंग ज़रूरी नहीं
Chrome 106 और उसके बाद के वर्शनअगर यह अनुरोध किसी फ़्रेम के लिए है और उसकी एक पैरंट फ़ाइल है, तो फ़्रेम के पैरंट दस्तावेज़ के लिए यूनीक आइडेंटिफ़ायर.
-
parentFrameId
नंबर
फ़्रेम का आईडी, जो अनुरोध भेजने वाले फ़्रेम को रैप करता है. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो -1 पर सेट करें.
-
requestId
स्ट्रिंग
अनुरोध का आईडी. ब्राउज़र सेशन में अनुरोध आईडी यूनीक होते हैं.
-
tabId
नंबर
उस टैब का आईडी जिसमें अनुरोध किया जाता है. अगर अनुरोध किसी टैब से न जुड़ा हो, तो उसे -1 पर सेट करें.
-
टाइप
अनुरोध का संसाधन टाइप.
-
यूआरएल
स्ट्रिंग
अनुरोध का यूआरएल.
RequestMethod
यह एक नेटवर्क अनुरोध की एचटीटीपी अनुरोध के तरीके के बारे में बताता है.
Enum
"get"
"head"
ResourceType
यह नेटवर्क अनुरोध के संसाधन प्रकार के बारे में बताता है.
Enum
"main_frame"
"sub_frame"
"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
"block"
नेटवर्क अनुरोध को ब्लॉक करें.
"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" को छोड़कर, सभी तरह के संसाधन ब्लॉक कर दिए जाते हैं. -
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
तरह के संसाधन शामिल हो सकते हैं. -
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
प्रॉपर्टी
-
चालू किया गया
boolean
नियमसेट डिफ़ॉल्ट रूप से चालू है या नहीं.
-
आईडी
स्ट्रिंग
एक ऐसी स्ट्रिंग जो खाली नहीं है, खास तौर पर नियमों के सेट की पहचान करती है. '_' से शुरू होने वाले आईडी, अंदरूनी इस्तेमाल के लिए रिज़र्व हैं.
-
पाथ
स्ट्रिंग
एक्सटेंशन डायरेक्ट्री से जुड़े JSON नियमों का पाथ.
RulesMatchedDetails
प्रॉपर्टी
-
rulesMatchedInfo
दिए गए फ़िल्टर से मेल खाने वाले नियम.
TabActionCountUpdate
प्रॉपर्टी
-
अधिक
नंबर
टैब की कार्रवाई की संख्या को बढ़ाना है. नेगेटिव वैल्यू से संख्या में कमी आएगी.
-
tabId
नंबर
वह टैब जिसके लिए कार्रवाई की संख्या को अपडेट करना है.
TestMatchOutcomeResult
प्रॉपर्टी
-
matchedRules
अगर कोई नियम है, तो वह काल्पनिक अनुरोध से मेल खाता है.
TestMatchRequestDetails
प्रॉपर्टी
-
शुरुआत करने वाला
स्ट्रिंग ज़रूरी नहीं
काल्पनिक अनुरोध के लिए, शुरुआत करने वाला यूआरएल (अगर कोई है).
-
method
RequestMethod ज़रूरी नहीं
काल्पनिक अनुरोध का स्टैंडर्ड एचटीटीपी तरीका. एचटीटीपी अनुरोधों के लिए डिफ़ॉल्ट रूप से "पाएं" होता है और बिना एचटीटीपी वाले अनुरोधों के लिए इसे अनदेखा कर दिया जाता है.
-
tabId
नंबर वैकल्पिक
उस टैब का आईडी जिसमें काल्पनिक अनुरोध किया जाता है. किसी असली टैब आईडी से मेल खाना ज़रूरी नहीं है. डिफ़ॉल्ट वैल्यू -1 होती है. इसका मतलब है कि अनुरोध किसी टैब से जुड़ा हुआ नहीं है.
-
टाइप
काल्पनिक अनुरोध का संसाधन टाइप.
-
यूआरएल
स्ट्रिंग
काल्पनिक अनुरोध का यूआरएल.
UnsupportedRegexReason
किसी रेगुलर एक्सप्रेशन के काम न करने की वजह बताता है.
Enum
"syntaxError"
रेगुलर एक्सप्रेशन के वाक्य गलत हैं या वह ऐसी सुविधाओं का इस्तेमाल करता है जो RE2 सिंटैक्स में उपलब्ध नहीं हैं.
"memoryLimitExceeded"
रेगुलर एक्सप्रेशन मेमोरी सीमा से ज़्यादा हो गया है.
UpdateRuleOptions
प्रॉपर्टी
-
addRules
नियम[] ज़रूरी नहीं
जोड़े जाने वाले नियम.
-
removeRuleIds
नंबर[] ज़रूरी नहीं
हटाए जाने वाले नियमों के आईडी. किसी भी अमान्य आईडी को अनदेखा कर दिया जाएगा.
UpdateRulesetOptions
प्रॉपर्टी
UpdateStaticRulesOptions
प्रॉपर्टी
URLTransform
प्रॉपर्टी
-
फ़्रैगमेंट
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया हिस्सा. यह जानकारी या तो खाली होनी चाहिए. इस स्थिति में, मौजूदा फ़्रैगमेंट हटा दिया जाएगा या यह '#' से शुरू होना चाहिए.
-
होस्ट
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया होस्ट.
-
पासवर्ड
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया पासवर्ड.
-
पाथ
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया पाथ. अगर खाली है, तो मौजूदा पाथ हटा दिया जाता है.
-
पोर्ट
स्ट्रिंग ज़रूरी नहीं
अनुरोध करने के लिए नया पोर्ट. अगर पोर्ट खाली है, तो मौजूदा पोर्ट हटा दिया जाता है.
-
query
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नई क्वेरी. या तो खाली होना चाहिए, किस स्थिति में मौजूदा क्वेरी हटा दी जाती है; या '?' से शुरू होना चाहिए.
-
queryTransform
QueryTransform ज़रूरी नहीं
क्वेरी के की-वैल्यू पेयर को जोड़ें, हटाएं या बदलें.
-
स्कीम
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नई स्कीम. "http", "https", "ftp", और "chrome-extension" वैल्यू का इस्तेमाल किया जा सकता है.
-
उपयोगकर्ता नाम
स्ट्रिंग ज़रूरी नहीं
अनुरोध के लिए नया उपयोगकर्ता नाम.
प्रॉपर्टी
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
-
सोलर पैनलों की संख्या
नंबर
-
सामान लौटाना
-
प्रॉमिस<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
स्ट्रिंग[]
-
सामान लौटाना
-
प्रॉमिस<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
सामान लौटाना
-
Promise<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
सामान लौटाना
-
Promise<void>
Chrome 91 और उसके बाद के वर्शनप्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और उसके बाद के वर्शन पर काम करता है. दूसरे प्लैटफ़ॉर्म को कॉलबैक इस्तेमाल करने होते हैं.
updateEnabledRulesets()
chrome.declarativeNetRequest.updateEnabledRulesets(
options: UpdateRulesetOptions,
callback?: function,
)
एक्सटेंशन के लिए चालू स्टैटिक नियमसेट के सेट को अपडेट करता है. सबसे पहले options.disableRulesetIds
में लिस्ट किए गए आईडी वाले रूलसेट जोड़े जाते हैं. इसके बाद, options.enableRulesetIds
में लिस्ट किए गए रूलसेट जोड़े जाते हैं.
ध्यान दें कि चालू स्टैटिक नियमसेट का सेट सभी सेशन में लागू रहता है, लेकिन एक्सटेंशन अपडेट में नहीं. इसका मतलब है कि rule_resources
मेनिफ़ेस्ट कुंजी, एक्सटेंशन के हर अपडेट पर चालू स्टैटिक नियमसेट के सेट को तय करेगी.
पैरामीटर
-
विकल्पChrome 87 और उसके बाद के वर्शन
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
सामान लौटाना
-
Promise<void>
Chrome 91 और उसके बाद के वर्शनप्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और उसके बाद के वर्शन पर काम करता है. दूसरे प्लैटफ़ॉर्म को कॉलबैक इस्तेमाल करने होते हैं.
updateSessionRules()
chrome.declarativeNetRequest.updateSessionRules(
options: UpdateRuleOptions,
callback?: function,
)
एक्सटेंशन के लिए, सेशन के दायरे वाले नियमों के मौजूदा सेट में बदलाव करता है. सबसे पहले options.removeRuleIds
में दिए गए आईडी वाले नियमों को हटाया जाता है. इसके बाद, options.addRules
में दिए गए नियम जोड़े जाते हैं. ध्यान दें:
- यह अपडेट एक ऐटमिक ऑपरेशन के तौर पर होता है: या तो सभी तय नियम जोड़े और हटा दिए जाते हैं या फिर कोई गड़बड़ी मिलती है.
- ये नियम सभी सेशन में लागू नहीं होते और मेमोरी में इनका इस्तेमाल किया जाता है.
MAX_NUMBER_OF_SESSION_RULES
से पता चलता है कि कोई एक्सटेंशन, ज़्यादा से ज़्यादा कितने सेशन नियम जोड़ सकता है.
पैरामीटर
-
विकल्प
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
सामान लौटाना
-
Promise<void>
Chrome 91 और उसके बाद के वर्शनप्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और उसके बाद के वर्शन पर काम करता है. दूसरे प्लैटफ़ॉर्म को कॉलबैक इस्तेमाल करने होते हैं.
updateStaticRules()
chrome.declarativeNetRequest.updateStaticRules(
options: UpdateStaticRulesOptions,
callback?: function,
)
यह Ruleset
में, अलग-अलग स्टैटिक नियमों को बंद और चालू करता है. बंद किए गए Ruleset
से जुड़े नियमों में किए गए बदलाव, अगली बार चालू होने पर लागू होंगे.
पैरामीटर
-
विकल्प
-
कॉलबैक
फ़ंक्शन वैकल्पिक
callback
पैरामीटर ऐसा दिखता है:() => void
सामान लौटाना
-
Promise<void>
प्रॉमिस सिर्फ़ मेनिफ़ेस्ट V3 और उसके बाद के वर्शन पर काम करता है. दूसरे प्लैटफ़ॉर्म को कॉलबैक इस्तेमाल करने होते हैं.
इवेंट
onRuleMatchedDebug
chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(
callback: function,
)
यह तब ट्रिगर होता है, जब किसी नियम का अनुरोध से मैच होता है. यह सिर्फ़ ऐसे एक्सटेंशन के लिए उपलब्ध है जिन्हें पैक नहीं किया गया है और जिनके पास "declarativeNetRequestFeedback"
की अनुमति है. ऐसा इसलिए, क्योंकि इसे सिर्फ़ डीबग करने के लिए इस्तेमाल किया जाता है.
पैरामीटर
-
कॉलबैक
function
callback
पैरामीटर ऐसा दिखता है:(info: MatchedRuleInfoDebug) => void
-
जानकारी
-