chrome.declarativeNetRequest

कंपनी का ब्यौरा

chrome.declarativeNetRequest एपीआई का इस्तेमाल, नेटवर्क के अनुरोधों को ब्लॉक करने या उनमें बदलाव करने के लिए किया जाता है. ऐसा, डिक्लेरेटिव टोन वाले नियमों के बारे में बताकर किया जाता है. इसकी मदद से, एक्सटेंशन नेटवर्क के अनुरोधों में बदलाव किए बिना, उनका कॉन्टेंट देखे बिना और नेटवर्क के अनुरोधों में बदलाव कर सकते हैं. इस तरह, एक्सटेंशन की निजता बनाए रखने में मदद मिलती है.

अनुमतियां

declarativeNetRequest
declarativeNetRequestWithHostAccess

"declarativeNetRequest" और "declarativeNetRequestWithHostAccess" अनुमतियां एक जैसी सुविधाएं देती हैं. इनमें अंतर यह होता है कि अनुमतियों के लिए अनुरोध किया गया है या उन्हें स्वीकार किया गया है.

"declarativeNetRequest"
इंस्टॉल के समय अनुमति से जुड़ी चेतावनी ट्रिगर करता है, लेकिन allow, allowAllRequests, और block के नियमों का इंप्लिसिट ऐक्सेस देता है. जब हो सके, तब इसका इस्तेमाल करें, ताकि होस्ट के पूरे ऐक्सेस का अनुरोध करने की ज़रूरत न पड़े.
"declarativeNetRequestFeedback"
यह नीति पैक नहीं किए गए एक्सटेंशन, खास तौर पर getMatchedRules() और onRuleMatchedDebug के लिए, डीबग करने की सुविधाएं चालू करती है.
"declarativeNetRequestWithHostAccess"
इंस्टॉल करते समय, अनुमति से जुड़ी चेतावनी नहीं दिखती है. हालांकि, किसी होस्ट पर कोई कार्रवाई करने से पहले, आपको होस्ट की अनुमतियों के लिए अनुरोध करना होगा. ऐसा करना तब सही रहता है, जब आपको किसी ऐसे एक्सटेंशन में डिक्लेरेटिव नेट रिक्वेस्ट नियमों का इस्तेमाल करना हो जिसके पास पहले से ही होस्ट की अनुमतियां हैं और वह किसी अन्य चेतावनी को जनरेट नहीं करता है.

उपलब्धता

Chrome 84 और उसके बाद के वर्शन पर

मेनिफ़ेस्ट

पहले बताई गई अनुमतियों के अलावा, कुछ खास तरह के रूलसेट, खास तौर पर स्टैटिक नियमसेट के लिए, "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

नियम की प्राथमिकता

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

  1. किसी एक्सटेंशन में मौजूद नियमों के लिए प्राथमिकता तय की जाती है.
  2. अगर एक से ज़्यादा एक्सटेंशन किसी अनुरोध पर एक नियम लागू कर सकते हैं, तो किसी खास अनुरोध से मेल खाने वाले सभी एक्सटेंशन के लिए प्राथमिकता तय की जाती है.

इस तरीके से मैच करने पर: किसी खास एक्सटेंशन के लिए तय किए गए किसी भी नियम को दूसरे एक्सटेंशन के नियमों के मुकाबले प्राथमिकता दी जाएगी.

किसी एक्सटेंशन में नियम की प्राथमिकता

किसी एक एक्सटेंशन में, नीचे दी गई प्रक्रिया का इस्तेमाल करके प्राथमिकता तय करने पर काम किया जाता है:

  1. डेवलपर की तय की गई सबसे ज़्यादा प्राथमिकता वाला नियम (दूसरे शब्दों में, "priority" फ़ील्ड) दिया जाता है.

  2. अगर डेवलपर की तय की गई प्राथमिकता वाले एक से ज़्यादा नियम हैं, तो "action" फ़ील्ड का इस्तेमाल करके नियमों को इस क्रम में प्राथमिकता दी जाती है:

    1. allow
    2. allowAllRequests
    3. block
    4. upgradeScheme
    5. redirect

  3. अगर कार्रवाई का टाइप block या redirect नहीं है, तो मेल खाने वाले modifyHeaders नियमों का आकलन किया जाता है. ध्यान रखें कि अगर ऐसे कोई नियम हैं जिनकी डेवलपर ने प्राथमिकता तय की है और allow और allowAllRequests के लिए तय की गई प्राथमिकता से कम है, तो ऐसे नियमों को अनदेखा किया जाता है.

  4. अगर कई नियम एक ही हेडर में बदलाव करते हैं, तो बदलाव को डेवलपर के बनाए गए "priority" फ़ील्ड और बताई गई कार्रवाइयों से तय किया जाता है.

    • अगर कोई नियम किसी हेडर में जोड़ा जाता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जोड़े जा सकते हैं. सेट करने और हटाने की कार्रवाइयों की अनुमति नहीं है.
    • अगर कोई नियम हेडर सेट करता है, तो कम प्राथमिकता वाले नियम सिर्फ़ उस हेडर में जोड़े जा सकते हैं. कोई और बदलाव करने की अनुमति नहीं है.
    • अगर कोई नियम हेडर को हटा देता है, तो कम प्राथमिकता वाले नियम हेडर में और बदलाव नहीं कर सकते.

एक्सटेंशन के बीच नियम की प्राथमिकता

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

  1. नियमों को "action" फ़ील्ड का इस्तेमाल करके, नीचे दिए गए क्रम में प्राथमिकता दी जाती है:

    1. block
    2. redirect या upgradeScheme
    3. allow या allowAllRequests

  2. अगर एक से ज़्यादा नियम मेल खाते हैं, तो सबसे हाल ही में इंस्टॉल किए गए एक्सटेंशन को प्राथमिकता दी जाती है.

सुरक्षित नियम

सुरक्षित नियम वे नियम होते हैं जिनमें block, allow, allowAllRequests या upgradeScheme की कार्रवाई होती है. ये नियम, ज़्यादा डाइनैमिक नियमों के कोटे के दायरे में आते हैं.

नियम की सीमाएं

ब्राउज़र में नियमों को लोड करने और उनका आकलन करने पर, परफ़ॉर्मेंस पर असर पड़ता है. इसलिए, एपीआई का इस्तेमाल करते समय कुछ सीमाएं लागू होती हैं. सीमाएं इस बात पर निर्भर करती हैं कि आपने किस तरह के नियम का इस्तेमाल किया है.

स्टैटिक नियम

स्टैटिक नियम वे नियम होते हैं जिनके बारे में मेनिफ़ेस्ट फ़ाइल में बताया जाता है. कोई एक्सटेंशन, "rule_resources" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर ज़्यादा से ज़्यादा 100 स्टैटिक rulesets तय कर सकता है. हालांकि, एक बार में इनमें से सिर्फ़ 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" कैटगरी का इस्तेमाल करना.

उदाहरण

कोड के उदाहरण

डाइनैमिक नियमों को अपडेट करना

नीचे दिए गए उदाहरण में, 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

Chrome 88 और उसके बाद के वर्शन

प्रॉपर्टी

  • displayActionCountAsBadgeText

    बूलियन ज़रूरी नहीं

    चुनें कि किसी पेज के लिए, ऐक्शन की संख्या को एक्सटेंशन के बैज टेक्स्ट के तौर पर अपने-आप दिखाना है या नहीं. यह प्राथमिकता सभी सेशन में लागू रहती है.

  • tabUpdate

    TabActionCountUpdate ज़रूरी नहीं है

    Chrome 89 और उसके बाद के वर्शन

    इस बारे में जानकारी कि टैब में की जाने वाली कार्रवाइयों की संख्या को कैसे अडजस्ट करना है.

GetDisabledRuleIdsOptions

Chrome 111 और उसके बाद वाले वर्शन के लिए

प्रॉपर्टी

  • rulesetId

    स्ट्रिंग

    स्टैटिक Ruleset से जुड़ा आईडी.

GetRulesFilter

Chrome 111 और उसके बाद वाले वर्शन के लिए

प्रॉपर्टी

  • ruleIds

    नंबर[] ज़रूरी नहीं

    अगर तय किया गया है, तो सिर्फ़ मेल खाने वाले आईडी वाले नियम शामिल किए जाते हैं.

HeaderOperation

Chrome 86 और उसके बाद के वर्शन

इससे "modifyHeaders" नियम के लिए संभावित कार्रवाइयों के बारे में पता चलता है.

Enum

"append"
बताए गए हेडर के लिए नई एंट्री जोड़ता है. अनुरोध के हेडर के लिए यह कार्रवाई नहीं की जा सकती.

"set"
खास हेडर के लिए नई वैल्यू सेट करता है और उसी नाम वाले किसी मौजूदा हेडर को हटाता है.

"हटाएं"
खास हेडर के लिए सभी एंट्री हटा देता है.

IsRegexSupportedResult

Chrome 87 और उसके बाद के वर्शन

प्रॉपर्टी

  • isSupported

    boolean

  • कारण

    UnsupportedRegexReason ज़रूरी नहीं है

    रेगुलर एक्सप्रेशन के काम न करने की वजह बताता है. सिर्फ़ तब दिया जाता है, जब isSupported गलत हो.

MatchedRule

प्रॉपर्टी

  • ruleId

    नंबर

    मिलते-जुलते नियम का आईडी.

  • rulesetId

    स्ट्रिंग

    उस Ruleset का आईडी जिससे यह नियम जुड़ा है. डाइनैमिक नियमों के सेट से शुरू होने वाले नियम के लिए, यह DYNAMIC_RULESET_ID के बराबर होगा.

MatchedRuleInfo

प्रॉपर्टी

  • नियम

    MatchedRule

  • tabId

    नंबर

    अगर टैब अब भी चालू है, तो उस टैब का tabId जिससे अनुरोध शुरू हुआ था. या फिर -1.

  • timeStamp

    नंबर

    नियम के मेल खाने का समय. टाइमस्टैंप, समय के लिए JavaScript के तौर-तरीकों के मुताबिक होंगे. जैसे, Epoch के बाद के मिलीसेकंड की संख्या.

MatchedRuleInfoDebug

प्रॉपर्टी

  • CANNOT TRANSLATE

    RequestDetails

    उस अनुरोध के बारे में जानकारी जिसके लिए नियम का मिलान किया गया था.

  • नियम

    MatchedRule

MatchedRulesFilter

प्रॉपर्टी

  • minTimeStamp

    नंबर वैकल्पिक

    अगर तय किया गया है, तो सिर्फ़ दिए गए टाइमस्टैंप के बाद नियमों का मिलान करता है.

  • tabId

    नंबर वैकल्पिक

    अगर तय किया गया है, तो सिर्फ़ दिए गए टैब के नियमों से मेल खाता है. अगर -1 पर सेट है, तो ऐसे नियमों से मेल खाता है जो किसी भी ऐक्टिव टैब से जुड़े नहीं हैं.

ModifyHeaderInfo

Chrome 86 और उसके बाद के वर्शन

प्रॉपर्टी

  • हेडर

    स्ट्रिंग

    हेडर का नाम, जिसमें बदलाव किया जाना है.

  • कार्रवाई

    HeaderOperation

    हेडर पर की जाने वाली कार्रवाई.

  • value

    स्ट्रिंग ज़रूरी नहीं

    हेडर के लिए नई वैल्यू. append और set कार्रवाइयों के लिए बताया जाना चाहिए.

QueryKeyValue

प्रॉपर्टी

  • बटन

    स्ट्रिंग

  • replaceOnly

    बूलियन ज़रूरी नहीं

    Chrome 94 और इसके बाद के वर्शन पर

    अगर सही है, तो क्वेरी कुंजी को सिर्फ़ तब बदला जाता है, जब वह पहले से मौजूद हो. अगर कुंजी मौजूद नहीं है, तो उसे भी जोड़ दिया जाता है. डिफ़ॉल्ट तौर पर, 'गलत' पर सेट होती है.

  • value

    स्ट्रिंग

QueryTransform

प्रॉपर्टी

  • addOrReplaceParams

    QueryKeyValue[] ज़रूरी नहीं

    जोड़ी या बदली जाने वाली क्वेरी के-वैल्यू पेयर की सूची.

  • removeParams

    स्ट्रिंग[] ज़रूरी नहीं

    हटाई जाने वाली क्वेरी कुंजियों की सूची.

Redirect

प्रॉपर्टी

  • extensionPath

    स्ट्रिंग ज़रूरी नहीं

    एक्सटेंशन डायरेक्ट्री से जुड़ा पाथ. '/' से शुरू होना चाहिए.

  • regexSubstitution

    स्ट्रिंग ज़रूरी नहीं

    regexFilter की जानकारी देने वाले नियमों के सब्सिटिट्यूशन पैटर्न. यूआरएल में regexFilter का पहला मिलान इस पैटर्न से बदल दिया जाएगा. regexSubstitution में, बैकस्लैश-एस्केप्ड डिजिट (\1 से \9) का इस्तेमाल करके, उनसे जुड़े कैप्चर ग्रुप शामिल किए जा सकते हैं. \0, मिलते-जुलते पूरे टेक्स्ट को दिखाता है.

  • रूपांतरित करें

    URLTransform वैकल्पिक

    किए जाने वाले यूआरएल में बदलाव करना.

  • यूआरएल

    स्ट्रिंग ज़रूरी नहीं

    दूसरा वेबलिंक. JavaScript यूआरएल पर रीडायरेक्ट करने की अनुमति नहीं है.

RegexOptions

Chrome 87 और उसके बाद के वर्शन

प्रॉपर्टी

  • 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 पर सेट करें.

  • टाइप

    ResourceType

    अनुरोध का संसाधन टाइप.

  • यूआरएल

    स्ट्रिंग

    अनुरोध का यूआरएल.

RequestMethod

Chrome 91 और उसके बाद के वर्शन

यह एक नेटवर्क अनुरोध की एचटीटीपी अनुरोध के तरीके के बारे में बताता है.

Enum

"get"

"head"

ResourceType

यह नेटवर्क अनुरोध के संसाधन प्रकार के बारे में बताता है.

Enum

"main_frame"

"sub_frame"

"font"

"object"

"xmlhttprequest"

"csp_report"

"websocket"

Rule

प्रॉपर्टी

  • ऐक्शन गेम

    RuleAction

    इस नियम के मेल खाने पर की जाने वाली कार्रवाई.

  • शर्त

    RuleCondition

    वह शर्त जिसके तहत यह नियम ट्रिगर होता है.

  • आईडी

    नंबर

    एक आईडी, जो किसी नियम की खास तौर पर पहचान करता है. यह ज़रूरी है और इसकी वैल्यू 1 या इससे ज़्यादा होनी चाहिए.

  • प्राथमिकता

    नंबर वैकल्पिक

    नियम की प्राथमिकता. डिफ़ॉल्ट तौर पर, यह वैल्यू 1 पर सेट होती है. वैल्यू तय होने पर, वैल्यू >= 1 होनी चाहिए.

RuleAction

प्रॉपर्टी

  • रीडायरेक्ट करो

    रीडायरेक्ट करना ज़रूरी नहीं

    रीडायरेक्ट करने का तरीका बताता है. यह सिर्फ़ रीडायरेक्ट के नियमों के लिए मान्य है.

  • requestHeaders

    ModifyHeaderInfo[] वैकल्पिक

    Chrome 86 और उसके बाद के वर्शन

    अनुरोध के लिए बदलाव करने के लिए अनुरोध हेडर. सिर्फ़ तब मान्य है, जब RuleActionType "modifyHeaders" हो.

  • responseHeaders

    ModifyHeaderInfo[] वैकल्पिक

    Chrome 86 और उसके बाद के वर्शन

    अनुरोध के लिए बदलाव करने के लिए रिस्पॉन्स हेडर. सिर्फ़ तब मान्य है, जब RuleActionType "modifyHeaders" हो.

  • टाइप

    RuleActionType

    की जाने वाली कार्रवाई का टाइप.

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

    MatchedRuleInfo[]

    दिए गए फ़िल्टर से मेल खाने वाले नियम.

TabActionCountUpdate

Chrome 89 और उसके बाद के वर्शन

प्रॉपर्टी

  • अधिक

    नंबर

    टैब की कार्रवाई की संख्या को बढ़ाना है. नेगेटिव वैल्यू से संख्या में कमी आएगी.

  • tabId

    नंबर

    वह टैब जिसके लिए कार्रवाई की संख्या को अपडेट करना है.

TestMatchOutcomeResult

Chrome 103 और उसके बाद के वर्शन

प्रॉपर्टी

  • matchedRules

    MatchedRule[]

    अगर कोई नियम है, तो वह काल्पनिक अनुरोध से मेल खाता है.

TestMatchRequestDetails

Chrome 103 और उसके बाद के वर्शन

प्रॉपर्टी

  • शुरुआत करने वाला

    स्ट्रिंग ज़रूरी नहीं

    काल्पनिक अनुरोध के लिए, शुरुआत करने वाला यूआरएल (अगर कोई है).

  • method

    RequestMethod ज़रूरी नहीं

    काल्पनिक अनुरोध का स्टैंडर्ड एचटीटीपी तरीका. एचटीटीपी अनुरोधों के लिए डिफ़ॉल्ट रूप से "पाएं" होता है और बिना एचटीटीपी वाले अनुरोधों के लिए इसे अनदेखा कर दिया जाता है.

  • tabId

    नंबर वैकल्पिक

    उस टैब का आईडी जिसमें काल्पनिक अनुरोध किया जाता है. किसी असली टैब आईडी से मेल खाना ज़रूरी नहीं है. डिफ़ॉल्ट वैल्यू -1 होती है. इसका मतलब है कि अनुरोध किसी टैब से जुड़ा हुआ नहीं है.

  • टाइप

    ResourceType

    काल्पनिक अनुरोध का संसाधन टाइप.

  • यूआरएल

    स्ट्रिंग

    काल्पनिक अनुरोध का यूआरएल.

UnsupportedRegexReason

Chrome 87 और उसके बाद के वर्शन

किसी रेगुलर एक्सप्रेशन के काम न करने की वजह बताता है.

Enum

"syntaxError"
रेगुलर एक्सप्रेशन के वाक्य गलत हैं या वह ऐसी सुविधाओं का इस्तेमाल करता है जो RE2 सिंटैक्स में उपलब्ध नहीं हैं.

"memoryLimitExceeded"
रेगुलर एक्सप्रेशन मेमोरी सीमा से ज़्यादा हो गया है.

UpdateRuleOptions

Chrome 87 और उसके बाद के वर्शन

प्रॉपर्टी

  • addRules

    नियम[] ज़रूरी नहीं

    जोड़े जाने वाले नियम.

  • removeRuleIds

    नंबर[] ज़रूरी नहीं

    हटाए जाने वाले नियमों के आईडी. किसी भी अमान्य आईडी को अनदेखा कर दिया जाएगा.

UpdateRulesetOptions

Chrome 87 और उसके बाद के वर्शन

प्रॉपर्टी

  • disableRulesetIds

    स्ट्रिंग[] ज़रूरी नहीं

    स्टैटिक Ruleset से जुड़े आईडी का सेट, जिसे बंद किया जाना चाहिए.

  • enableRulesetIds

    स्ट्रिंग[] ज़रूरी नहीं

    स्टैटिक Ruleset से जुड़े आईडी का सेट, जिसे चालू किया जाना चाहिए.

UpdateStaticRulesOptions

Chrome 111 और उसके बाद वाले वर्शन के लिए

प्रॉपर्टी

  • disableRuleIds

    नंबर[] ज़रूरी नहीं

    Ruleset में नियमों के मुताबिक आईडी का सेट बंद किया जाना है.

  • enableRuleIds

    नंबर[] ज़रूरी नहीं

    चालू करने के लिए, Ruleset के नियमों के हिसाब से आईडी का सेट.

  • rulesetId

    स्ट्रिंग

    स्टैटिक Ruleset से जुड़ा आईडी.

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

Chrome 89 और उसके बाद के वर्शन

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

वैल्यू

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

Chrome 94 और इसके बाद के वर्शन पर

स्टैटिक Rulesets की ज़्यादा से ज़्यादा संख्या, जिसे कोई एक्सटेंशन एक बार में चालू कर सकता है.

वैल्यू

50

MAX_NUMBER_OF_REGEX_RULES

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

वैल्यू

1,000

MAX_NUMBER_OF_SESSION_RULES

Chrome 120 और इसके बाद के वर्शन

सेशन के स्कोप वाले ऐसे नियमों की ज़्यादा से ज़्यादा संख्या जिन्हें एक्सटेंशन जोड़ सकता है.

वैल्यू

5,000

MAX_NUMBER_OF_STATIC_RULESETS

स्टैटिक Rulesets की ज़्यादा से ज़्यादा संख्या, जिसे कोई एक्सटेंशन, "rule_resources" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर तय कर सकता है.

वैल्यू

100

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

Chrome 120 और इसके बाद के वर्शन

"असुरक्षित" डाइनैमिक नियमों की ज़्यादा से ज़्यादा संख्या, जिन्हें कोई एक्सटेंशन जोड़ सकता है.

वैल्यू

5,000

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

Chrome 120 और इसके बाद के वर्शन

"असुरक्षित" सेशन के दायरे वाले ऐसे नियमों की ज़्यादा से ज़्यादा संख्या जिन्हें कोई एक्सटेंशन जोड़ सकता है.

वैल्यू

5,000

SESSION_RULESET_ID

Chrome 90 और इसके बाद के वर्शन

सेशन के स्कोप वाले उन नियमों के लिए रूलसेट आईडी जिन्हें एक्सटेंशन ने जोड़ा है.

वैल्यू

"_session"

तरीके

getAvailableStaticRuleCount()

वादा Chrome 89+ 
chrome.declarativeNetRequest.getAvailableStaticRuleCount(
  callback?: function,
)

यह फ़ंक्शन ऐसे स्टैटिक नियमों की संख्या दिखाता है जिन्हें ग्लोबल स्टैटिक नियम सीमा पूरी होने से पहले, किसी एक्सटेंशन को चालू किया जा सकता है.

पैरामीटर

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (count: number) => void

    • सोलर पैनलों की संख्या

      नंबर

सामान लौटाना

  • प्रॉमिस<number>

    Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

getDisabledRuleIds()

वादा Chrome 111+ 
chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
  callback?: function,
)

यह विकल्प, दिए गए Ruleset में उन स्टैटिक नियमों की सूची दिखाता है जो फ़िलहाल बंद हैं.

पैरामीटर

  • विकल्प

    GetDisabledRuleIdsOptions

    क्वेरी के लिए नियमसेट के बारे में बताता है.

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    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

सामान लौटाना

  • Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

getSessionRules()

वादा Chrome 90+ 
chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
  callback?: function,
)

यह एक्सटेंशन के लिए, सेशन के स्कोप वाले नियमों का मौजूदा सेट दिखाता है. कॉलर, filter की जानकारी देकर, फ़ेच किए गए नियमों की सूची को फ़िल्टर कर सकते हैं.

पैरामीटर

  • फ़िल्‍टर

    GetRulesFilter ज़रूरी नहीं

    Chrome 111 और उसके बाद वाले वर्शन के लिए

    फ़ेच किए गए नियमों की सूची को फ़िल्टर करने के लिए एक ऑब्जेक्ट.

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (rules: Rule[]) => void

सामान लौटाना

  • वादा<नियम[]>

    Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

isRegexSupported()

वादा Chrome 87+ 
chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
  callback?: function,
)

यह जांचता है कि दिया गया रेगुलर एक्सप्रेशन, regexFilter नियम की शर्त के तौर पर काम करेगा.

पैरामीटर

  • regexOptions

    RegexOptions

    जांचा जाने वाला रेगुलर एक्सप्रेशन.

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    (result: IsRegexSupportedResult) => void

सामान लौटाना

  • Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

setExtensionActionOptions()

वादा Chrome 88+ 
chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
  callback?: function,
)

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

पैरामीटर

  • विकल्प

    ExtensionActionOptions

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    Chrome 89 और उसके बाद के वर्शन

    callback पैरामीटर ऐसा दिखता है: 

    () => void

सामान लौटाना

  • Promise<void>

    Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

testMatchOutcome()

वादा Chrome 103+ 
chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
  callback?: function,
)

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

पैरामीटर

सामान लौटाना

  • मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

updateDynamicRules()

वादा 
chrome.declarativeNetRequest.updateDynamicRules(
  options: UpdateRuleOptions,
  callback?: function,
)

यह एक्सटेंशन के लिए, डाइनैमिक नियमों के मौजूदा सेट में बदलाव करता है. सबसे पहले options.removeRuleIds में दिए गए आईडी वाले नियमों को हटाया जाता है. इसके बाद, options.addRules में दिए गए नियम जोड़े जाते हैं. ध्यान दें:

  • यह अपडेट एक ऐटमिक ऑपरेशन के तौर पर होता है: या तो सभी तय नियम जोड़े और हटा दिए जाते हैं या फिर कोई गड़बड़ी मिलती है.
  • ये नियम, सभी ब्राउज़र सेशन और एक्सटेंशन अपडेट में लागू रहते हैं.
  • एक्सटेंशन पैकेज के हिस्से के तौर पर बताए गए स्टैटिक नियमों को इस फ़ंक्शन का इस्तेमाल करके हटाया नहीं जा सकता.
  • MAX_NUMBER_OF_DYNAMIC_RULES किसी एक्सटेंशन के ज़रिए जोड़े जा सकने वाले डाइनैमिक नियमों की ज़्यादा से ज़्यादा संख्या होती है. असुरक्षित नियमों की संख्या MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES से ज़्यादा नहीं होनी चाहिए.

पैरामीटर

  • विकल्प

    UpdateRuleOptions

    Chrome 87 और उसके बाद के वर्शन
  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

सामान लौटाना

  • Promise<void>

    Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

updateEnabledRulesets()

वादा 
chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
  callback?: function,
)

एक्सटेंशन के लिए चालू स्टैटिक नियमसेट के सेट को अपडेट करता है. सबसे पहले options.disableRulesetIds में लिस्ट किए गए आईडी वाले रूलसेट जोड़े जाते हैं. इसके बाद, options.enableRulesetIds में लिस्ट किए गए रूलसेट जोड़े जाते हैं. ध्यान दें कि चालू स्टैटिक नियमसेट का सेट सभी सेशन में लागू रहता है, लेकिन एक्सटेंशन अपडेट में नहीं. इसका मतलब है कि rule_resources मेनिफ़ेस्ट कुंजी, एक्सटेंशन के हर अपडेट पर चालू स्टैटिक नियमसेट के सेट को तय करेगी.

पैरामीटर

  • विकल्प

    UpdateRulesetOptions

    Chrome 87 और उसके बाद के वर्शन
  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

सामान लौटाना

  • Promise<void>

    Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

updateSessionRules()

वादा Chrome 90+ 
chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
  callback?: function,
)

एक्सटेंशन के लिए, सेशन के दायरे वाले नियमों के मौजूदा सेट में बदलाव करता है. सबसे पहले options.removeRuleIds में दिए गए आईडी वाले नियमों को हटाया जाता है. इसके बाद, options.addRules में दिए गए नियम जोड़े जाते हैं. ध्यान दें:

  • यह अपडेट एक ऐटमिक ऑपरेशन के तौर पर होता है: या तो सभी तय नियम जोड़े और हटा दिए जाते हैं या फिर कोई गड़बड़ी मिलती है.
  • ये नियम सभी सेशन में लागू नहीं होते और मेमोरी में इनका इस्तेमाल किया जाता है.
  • MAX_NUMBER_OF_SESSION_RULES से पता चलता है कि कोई एक्सटेंशन, ज़्यादा से ज़्यादा कितने सेशन नियम जोड़ सकता है.

पैरामीटर

  • विकल्प

    UpdateRuleOptions

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

सामान लौटाना

  • Promise<void>

    Chrome 91 और उसके बाद के वर्शन

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

updateStaticRules()

वादा Chrome 111+ 
chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
  callback?: function,
)

यह Ruleset में, अलग-अलग स्टैटिक नियमों को बंद और चालू करता है. बंद किए गए Ruleset से जुड़े नियमों में किए गए बदलाव, अगली बार चालू होने पर लागू होंगे.

पैरामीटर

  • विकल्प

    UpdateStaticRulesOptions

  • कॉलबैक

    फ़ंक्शन वैकल्पिक

    callback पैरामीटर ऐसा दिखता है: 

    () => void

सामान लौटाना

  • Promise<void>

    मेनिफ़ेस्ट V3 और उसके बाद के वर्शन में प्रॉमिस काम करते हैं. हालांकि, पुराने सिस्टम के साथ काम करने के लिए कॉलबैक की सुविधा दी जाती है. एक ही फ़ंक्शन कॉल में दोनों का इस्तेमाल नहीं किया जा सकता. प्रॉमिस उसी तरह का है जो कॉलबैक को पास किया जाता है.

इवेंट

onRuleMatchedDebug

chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(
  callback: function,
)

यह तब ट्रिगर होता है, जब किसी नियम का अनुरोध से मैच होता है. यह सिर्फ़ ऐसे एक्सटेंशन के लिए उपलब्ध है जिन्हें पैक नहीं किया गया है और जिनके पास "declarativeNetRequestFeedback" की अनुमति है. ऐसा इसलिए, क्योंकि इसे सिर्फ़ डीबग करने के लिए इस्तेमाल किया जाता है.

पैरामीटर