chrome.declarativeNetRequest

ब्यौरा

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

अनुमतियां

declarativeNetRequest
declarativeNetRequestWithHostAccess

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

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

उपलब्धता

Chrome 84 या इसके बाद का वर्शन

मेनिफ़ेस्ट

ऊपर बताई गई अनुमतियों के अलावा, कुछ तरह के नियम सेट के लिए "declarative_net_request" मेनिफ़ेस्ट कुंजी का एलान करना ज़रूरी है. खास तौर पर, स्टैटिक नियम सेट के लिए. यह एक डिक्शनरी होनी चाहिए, जिसमें "rule_resources" नाम की एक कुंजी हो. यह कुंजी, Ruleset टाइप की डिक्शनरी वाला एक कलेक्शन है. इसे यहां दिखाया गया है. (ध्यान दें कि मेनिफ़ेस्ट के JSON में 'Ruleset' नाम नहीं दिखता, क्योंकि यह सिर्फ़ एक ऐरे है.) स्टैटिक नियमों के सेट के बारे में इस दस्तावेज़ में बाद में बताया गया है.

{
  "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/*"
  ],
  ...
}

नियम और नियमसेट

इस एपीआई का इस्तेमाल करने के लिए, एक या उससे ज़्यादा नियम सेट तय करें. नियमों के सेट में नियमों की एक श्रेणी होती है. एक नियम इनमें से कोई एक काम करता है:

  • नेटवर्क के किसी अनुरोध को ब्लॉक करें.
  • स्कीमा को अपग्रेड करें (एचटीटीपी से एचटीटीपीएस).
  • यह अनुरोध को ब्लॉक करने वाले किसी भी नियम को खारिज करके, अनुरोध को ब्लॉक होने से रोकता है.
  • नेटवर्क अनुरोध को रीडायरेक्ट करना.
  • अनुरोध या जवाब के हेडर में बदलाव करें.

तीन तरह के नियम सेट होते हैं, जिन्हें मैनेज करने के तरीके थोड़े अलग होते हैं.

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

डाइनैमिक और सेशन के स्कोप वाले नियमों का सेट

एक्सटेंशन का इस्तेमाल करते समय, डाइनैमिक और सेशन के नियमों के सेट को JavaScript की मदद से मैनेज किया जाता है.

  • डाइनैमिक नियम, ब्राउज़र सेशन और एक्सटेंशन अपग्रेड के दौरान बने रहते हैं.
  • ब्राउज़र बंद होने पर और एक्सटेंशन का नया वर्शन इंस्टॉल होने पर, सेशन के नियम मिट जाते हैं.

इनमें से हर तरह के नियम सेट का सिर्फ़ एक नियम होता है. एक्सटेंशन, updateDynamicRules() और updateSessionRules() को कॉल करके, नियमों को डाइनैमिक तरीके से जोड़ या हटा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब नियमों की सीमाएं पूरी न हुई हों. नियमों की सीमाओं के बारे में जानकारी पाने के लिए, नियमों की सीमाएं लेख पढ़ें. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.

स्टैटिक नियमों के सेट

डाइनैमिक और सेशन के नियमों के उलट, स्टैटिक नियमों को पैकेज किया जाता है. साथ ही, जब कोई एक्सटेंशन इंस्टॉल या अपग्रेड किया जाता है, तब इन्हें इंस्टॉल और अपडेट किया जाता है. इन्हें JSON फ़ॉर्मैट में नियम वाली फ़ाइलों में सेव किया जाता है. एक्सटेंशन को इनकी जानकारी देने के लिए, "declarative_net_request" और "rule_resources" कुंजियों का इस्तेमाल किया जाता है जैसा कि ऊपर बताया गया है. साथ ही, एक या उससे ज़्यादा Ruleset डिक्शनरी का इस्तेमाल किया जाता है. Ruleset डिक्शनरी में, नियम वाली फ़ाइल का पाथ, फ़ाइल में मौजूद नियमों के सेट का आईडी, और यह जानकारी होती है कि नियमों का सेट चालू है या बंद है. जब प्रोग्राम के हिसाब से नियमों के सेट को चालू या बंद किया जाता है, तो आखिरी दो विकल्प ज़रूरी होते हैं.

{
  ...
  "declarative_net_request" : {
    "rule_resources" : [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules_1.json"
    },
    ...
    ]
  }
  ...
}

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

जल्द समीक्षा

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

स्थैतिक नियमों और नियम सेट को चालू और बंद करना

स्टैटिक नियमों के अलग-अलग सेट और पूरे स्टैटिक नियमों के सेट, दोनों को रनटाइम के दौरान चालू या बंद किया जा सकता है.

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

परफ़ॉर्मेंस को बेहतर बनाए रखने के लिए, एक साथ चालू किए जा सकने वाले नियमों और नियम सेट की संख्या पर भी पाबंदियां हैं. getAvailableStaticRuleCount() को कॉल करके, यह पता लगाएं कि कितने अतिरिक्त नियम चालू किए जा सकते हैं. नियमों की सीमाओं के बारे में जानकारी पाने के लिए, नियमों की सीमाएं लेख पढ़ें.

स्टैटिक नियम को चालू या बंद करने के लिए, updateStaticRules() को कॉल करें. यह तरीका, UpdateStaticRulesOptions ऑब्जेक्ट लेता है. इसमें उन नियमों के आईडी की कैटगरी होती है जिन्हें चालू या बंद करना है. आईडी, Ruleset डिक्शनरी की "id" कुंजी का इस्तेमाल करके तय किए जाते हैं. बंद किए गए स्टैटिक नियमों की ज़्यादा से ज़्यादा संख्या 5,000 हो सकती है.

स्टैटिक नियमों के सेट को चालू या बंद करने के लिए, updateEnabledRulesets() को कॉल करें. यह तरीका, UpdateRulesetOptions ऑब्जेक्ट लेता है. इसमें उन नियमों के सेट के आईडी की कैटगरी होती है जिन्हें चालू या बंद करना है. आईडी, Ruleset डिक्शनरी की "id" कुंजी का इस्तेमाल करके तय किए जाते हैं.

नियम बनाना

टाइप कोई भी हो, नियम की शुरुआत चार फ़ील्ड से होती है. जैसा कि यहां दिखाया गया है. "id" और "priority" कुंजियों में संख्या का इस्तेमाल किया जाता है. वहीं, "action" और "condition" कुंजियों में, कई तरह की ब्लॉक करने और रीडायरेक्ट करने की शर्तें दी जा सकती हैं. यहां दिया गया नियम, "foo.com" से शुरू होने वाले सभी स्क्रिप्ट अनुरोधों को ब्लॉक करता है. ये अनुरोध, ऐसे किसी भी यूआरएल के लिए किए जाते हैं जिसमें "abc" सबस्ट्रिंग के तौर पर मौजूद हो.

{
  "id" : 1,
  "priority": 1,
  "action" : { "type" : "block" },
  "condition" : {
    "urlFilter" : "abc",
    "initiatorDomains" : ["foo.com"],
    "resourceTypes" : ["script"]
  }
}

यूआरएल मैचिंग

डिक्लेरेटिव नेट रिक्वेस्ट की मदद से, यूआरएल का मिलान पैटर्न मैचिंग सिंटैक्स या रेगुलर एक्सप्रेशन से किया जा सकता है.

यूआरएल फ़िल्टर का सिंटैक्स

किसी नियम की "condition" कुंजी, किसी तय किए गए डोमेन के यूआरएल पर कार्रवाई करने के लिए "urlFilter" कुंजी की अनुमति देती है. पैटर्न मैचिंग टोकन का इस्तेमाल करके पैटर्न बनाए जाते हैं. यहां कुछ उदाहरण दिए गए हैं.

urlFilter मैच मिलान नहीं होता है
"abc" https://abcd.com
https://example.com/abcd		 https://ab.com
"abc*d" https://abcd.com
https://example.com/abcxyzd		 https://abc.com
"||a.example.com" https://a.example.com/
https://b.a.example.com/xyz
https://a.example.company		 https://example.com/
"|https*" https://example.com http://example.com/
http://https.com
"example*^123|" https://example.com/123
http://abc.com/example?123		 https://example.com/1234
https://abc.com/example0123

रेगुलर एक्सप्रेशन

कंडीशन में रेगुलर एक्सप्रेशन का इस्तेमाल भी किया जा सकता है. "regexFilter" कुंजी देखें. इन शर्तों पर लागू होने वाली सीमाओं के बारे में जानने के लिए, रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम देखें.

यूआरएल के लिए अच्छी शर्तें लिखना

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

  • google.com, https://example.com/?param=google.com से गलत तरीके से मैच करता है
  • ||google.com, https://google.company से गलत तरीके से मैच करता है
  • https://www.google.com, https://example.com/?param=https://www.google.com से गलत तरीके से मैच करता है

इनका इस्तेमाल करें:

  • ||google.com/, जो सभी पाथ और सभी सबडोमेन से मेल खाता है.
  • |https://www.google.com/ जो सभी पाथ से मेल खाता है, लेकिन किसी भी सबडोमेन से नहीं.

इसी तरह, रेगुलर एक्सप्रेशन को ऐंकर करने के लिए ^ और / वर्णों का इस्तेमाल करें. उदाहरण के लिए, ^https:\/\/p.rizon.top:443\/https\/www\.google\.com\/ https://www.google.com पर मौजूद किसी भी पाथ से मेल खाता है.

नियम का आकलन

डीएनआर के नियमों को ब्राउज़र, नेटवर्क अनुरोध के लाइफ़साइकल के अलग-अलग चरणों में लागू करता है.

अनुरोध करने से पहले

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

हर एक्सटेंशन के लिए, ब्राउज़र मैच करने वाले नियमों की सूची तय करता है. जिन नियमों में modifyHeaders कार्रवाई की गई है उन्हें यहां शामिल नहीं किया गया है, क्योंकि उन्हें बाद में मैनेज किया जाएगा. इसके अलावा, responseHeaders शर्त वाले नियमों पर बाद में विचार किया जाएगा. ऐसा तब होगा, जब रिस्पॉन्स हेडर उपलब्ध होंगे. इसलिए, इन्हें शामिल नहीं किया गया है.

इसके बाद, Chrome हर एक्सटेंशन के लिए, हर अनुरोध के हिसाब से ज़्यादा से ज़्यादा एक उम्मीदवार चुनता है. Chrome, प्राथमिकता के हिसाब से मिलते-जुलते सभी नियमों को क्रम से लगाकर, मिलता-जुलता कोई नियम ढूंढता है. एक जैसी प्राथमिकता वाले नियमों को कार्रवाई के हिसाब से क्रम में लगाया जाता है (allow या allowAllRequests > block > upgradeScheme > redirect).

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

अगर एक से ज़्यादा एक्सटेंशन इस अनुरोध को ब्लॉक या रीडायरेक्ट करना चाहते हैं, तो कार्रवाई करने के लिए एक विकल्प चुना जाता है. Chrome, नियमों को block > redirect या upgradeScheme > allow या allowAllRequests के क्रम में लगाकर ऐसा करता है. अगर दो नियम एक ही तरह के हैं, तो Chrome उस नियम को चुनता है जो हाल ही में इंस्टॉल किए गए एक्सटेंशन से जुड़ा है.

अनुरोध के हेडर भेजे जाने से पहले

Chrome, सर्वर को अनुरोध हेडर भेजता है. इससे पहले, हेडर को मैच करने वाले modifyHeaders नियमों के आधार पर अपडेट किया जाता है.

Chrome, एक ही एक्सटेंशन में बदलावों की सूची बनाता है. इसके लिए, वह मिलते-जुलते सभी modifyHeaders नियमों को ढूंढता है. पहले की तरह, सिर्फ़ वे नियम शामिल किए जाते हैं जिनकी प्राथमिकता, मेल खाने वाले किसी भी allow या allowAllRequests नियम से ज़्यादा होती है.

Chrome इन नियमों को इस क्रम में लागू करता है कि हाल ही में इंस्टॉल किए गए एक्सटेंशन के नियमों का आकलन हमेशा पुराने एक्सटेंशन के नियमों से पहले किया जाता है. इसके अलावा, एक एक्सटेंशन के ज़्यादा प्राथमिकता वाले नियम, उसी एक्सटेंशन के कम प्राथमिकता वाले नियमों से पहले लागू होते हैं. खास तौर पर, अलग-अलग एक्सटेंशन के लिए भी:

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

जवाब मिलने के बाद

जवाब के हेडर मिलने के बाद, Chrome responseHeaders शर्त वाले नियमों का आकलन करता है.

इन नियमों को action और priority के हिसाब से क्रम में लगाने के बाद, Chrome उन नियमों को हटा सकता है जो allow या allowAllRequests से मिलते-जुलते हैं. ऐसा "अनुरोध से पहले" सेक्शन में बताए गए चरणों के हिसाब से होता है. इसके बाद, Chrome किसी एक्सटेंशन की ओर से किए गए अनुरोध को ब्लॉक कर सकता है या उसे रीडायरेक्ट कर सकता है.

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

ब्लॉक करने के नियम के मामले में, अनुरोध करने वाले पेज को ब्लॉक किया गया रिस्पॉन्स मिलता है. साथ ही, Chrome अनुरोध को पहले ही बंद कर देता है. रीडायरेक्ट करने के नियम के मामले में, Chrome रीडायरेक्ट किए गए यूआरएल के लिए नया अनुरोध करता है. पक्का करें कि ये गतिविधियां, आपके एक्सटेंशन के लिए निजता से जुड़ी उम्मीदों को पूरा करती हों.

अगर अनुरोध को ब्लॉक या रीडायरेक्ट नहीं किया जाता है, तो Chrome, modifyHeaders के सभी नियमों को लागू करता है. जवाब के हेडर में बदलाव करने का तरीका, "अनुरोध के हेडर भेजे जाने से पहले" सेक्शन में बताए गए तरीके जैसा ही होता है. अनुरोध के हेडर में बदलाव करने से कोई फ़र्क़ नहीं पड़ता, क्योंकि अनुरोध पहले ही किया जा चुका है.

सुरक्षा के नियम

सुरक्षित नियमों को ऐसे नियमों के तौर पर तय किया जाता है जिनमें block, allow, allowAllRequests या upgradeScheme कार्रवाई शामिल होती है. इन नियमों पर, डाइनैमिक नियमों के लिए तय कोटा लागू होता है.

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

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

स्टैटिक नियम

स्टैटिक नियम वे होते हैं जो मेनिफ़ेस्ट फ़ाइल में बताए गए नियम फ़ाइलों में तय किए जाते हैं. कोई एक्सटेंशन, "rule_resources" मेनिफ़ेस्ट कुंजी के हिस्से के तौर पर ज़्यादा से ज़्यादा 100 स्टैटिक ruleset तय कर सकता है. हालांकि, इनमें से सिर्फ़ 50 ruleset एक बार में चालू किए जा सकते हैं. दूसरे को MAX_NUMBER_OF_ENABLED_STATIC_RULESETS कहा जाता है. इन सभी नियम सेट में, कम से कम 30,000 नियम होने की गारंटी है. इसे GUARANTEED_MINIMUM_STATIC_RULES कहा जाता है.

इसके बाद, उपलब्ध नियमों की संख्या इस बात पर निर्भर करती है कि उपयोगकर्ता के ब्राउज़र पर इंस्टॉल किए गए सभी एक्सटेंशन ने कितने नियम चालू किए हैं. getAvailableStaticRuleCount() को कॉल करके, रनटाइम के दौरान इस नंबर का पता लगाया जा सकता है. कोड के उदाहरण में जाकर, इसका उदाहरण देखा जा सकता है.

सेशन के नियम

किसी एक्सटेंशन में ज़्यादा से ज़्यादा 5,000 सेशन के नियम हो सकते हैं. इसे MAX_NUMBER_OF_SESSION_RULES के तौर पर दिखाया जाता है.

Chrome 120 से पहले, डाइनैमिक और सेशन के नियमों को मिलाकर 5,000 नियम बनाए जा सकते थे.

डाइनैमिक नियम

किसी एक्सटेंशन में कम से कम 5,000 डाइनैमिक नियम हो सकते हैं. इसे MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES के तौर पर दिखाया जाता है.

Chrome 121 से, सुरक्षित डाइनैमिक नियमों के लिए ज़्यादा सीमा तय की गई है. अब 30,000 नियम उपलब्ध हैं. इन्हें MAX_NUMBER_OF_DYNAMIC_RULES के तौर पर दिखाया जाता है. सुरक्षित न मानी जाने वाली ऐसी कोई भी नियम, जिसे 5,000 नियमों की सीमा के अंदर जोड़ा गया है उसे भी इस सीमा में गिना जाएगा.

Chrome 120 से पहले, डाइनैमिक और सेशन के नियमों को मिलाकर 5,000 नियमों को लागू किया जा सकता था.

रेगुलर एक्सप्रेशन का इस्तेमाल करने वाले नियम

सभी तरह के नियमों में रेगुलर एक्सप्रेशन का इस्तेमाल किया जा सकता है. हालांकि, हर टाइप के रेगुलर एक्सप्रेशन नियमों की कुल संख्या 1,000 से ज़्यादा नहीं हो सकती. इसे MAX_NUMBER_OF_REGEX_RULES कहा जाता है.

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

rules_1.json: Rule with id 1 specified a more complex regex than allowed
as part of the "regexFilter" key.

सर्विस वर्कर के साथ इंटरैक्शन

declarativeNetRequest सिर्फ़ उन अनुरोधों पर लागू होता है जो नेटवर्क स्टैक तक पहुंचते हैं. इसमें एचटीटीपी कैश से मिले रिस्पॉन्स शामिल हैं. हालांकि, इसमें वे रिस्पॉन्स शामिल नहीं हो सकते जो सर्विस वर्कर के onfetch हैंडलर से होकर गुज़रते हैं. declarativeNetRequest, सर्विस वर्कर से जनरेट हुए या CacheStorage से वापस लाए गए रिस्पॉन्स पर असर नहीं डालेगा. हालांकि, यह सर्विस वर्कर में किए गए fetch() कॉल पर असर डालेगा.

वेब पर ऐक्सेस किए जा सकने वाले संसाधन

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

हेडर में बदलाव करना

अपेंड करने की सुविधा सिर्फ़ इन हेडर के लिए उपलब्ध है: accept, accept-encoding, accept-language, access-control-request-headers, cache-control, connection, content-language, cookie, forwarded, if-match, if-none-match, keep-alive, range, te, trailer, transfer-encoding, upgrade, user-agent, via, want-digest, x-forwarded-for.

उदाहरण

कोड के उदाहरण

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

यहां दिए गए उदाहरण में, updateDynamicRules() को कॉल करने का तरीका बताया गया है. updateSessionRules() के लिए भी यही तरीका अपनाएं.

// Get arrays containing new and old rules
const newRules = await getNewRules();
const oldRules = await chrome.declarativeNetRequest.getDynamicRules();
const oldRuleIds = oldRules.map(rule => rule.id);

// Use the arrays to update the dynamic rules
await chrome.declarativeNetRequest.updateDynamicRules({
  removeRuleIds: oldRuleIds,
  addRules: newRules
});

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

यहां दिए गए उदाहरण में बताया गया है कि उपलब्ध और चालू किए गए स्टैटिक नियमों के सेट की संख्या को ध्यान में रखते हुए, नियमों के सेट को चालू और बंद कैसे करें. ऐसा तब किया जाता है, जब आपको तय सीमा से ज़्यादा स्टैटिक नियमों की ज़रूरत होती है. इसके लिए, आपके कुछ नियम सेट इंस्टॉल होने चाहिए. साथ ही, मेनिफ़ेस्ट फ़ाइल में "Enabled" को false पर सेट करके, कुछ नियम सेट बंद होने चाहिए.

async function updateStaticRules(enableRulesetIds, disableCandidateIds) {
  // Create the options structure for the call to updateEnabledRulesets()
  let options = { enableRulesetIds: enableRulesetIds }
  // Get the number of enabled static rules
  const enabledStaticCount = await chrome.declarativeNetRequest.getEnabledRulesets();
  // Compare rule counts to determine if anything needs to be disabled so that
  // new rules can be enabled
  const proposedCount = enableRulesetIds.length;
  if (enabledStaticCount + proposedCount > chrome.declarativeNetRequest.MAX_NUMBER_OF_ENABLED_STATIC_RULESETS) {
    options.disableRulesetIds = disableCandidateIds
  }
  // Update the enabled static rules
  await chrome.declarativeNetRequest.updateEnabledRulesets(options);
}

नियमों के उदाहरण

यहां दिए गए उदाहरणों में बताया गया है कि Chrome, एक्सटेंशन में नियमों को किस तरह प्राथमिकता देता है. इनकी समीक्षा करते समय, प्राथमिकता तय करने के नियमों को अलग विंडो में खोला जा सकता है.

"priority" कुंजी

इन उदाहरणों के लिए, *://*.example.com/* करने के लिए होस्ट करने की अनुमति ज़रूरी है.

किसी यूआरएल की प्राथमिकता तय करने के लिए, (डेवलपर के तय किए गए) "priority" कुंजी, "action" कुंजी, और "urlFilter" कुंजी देखें. इन उदाहरणों में, नीचे दिखाई गई उदाहरण के तौर पर दी गई नियम फ़ाइल का इस्तेमाल किया गया है.

https://google.com पर नेविगेट करना
इस यूआरएल पर दो नियम लागू होते हैं: आईडी 1 और 4 वाले नियम. आईडी 1 वाला नियम लागू होता है, क्योंकि "block" कार्रवाइयों की प्राथमिकता "redirect" कार्रवाइयों से ज़्यादा होती है. बाकी नियम लागू नहीं होते, क्योंकि वे लंबे यूआरएल के लिए हैं.
https://google.com/1234 पर नेविगेट करना
यूआरएल लंबा होने की वजह से, आईडी 2 वाला नियम अब आईडी 1 और 4 वाले नियमों के साथ भी मेल खाता है. आईडी 2 वाला नियम लागू होता है, क्योंकि "allow" की प्राथमिकता "block" और "redirect" से ज़्यादा है.
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"]
  }
}

यहां "transform" कुंजी का इस्तेमाल करके, example.com के सबडोमेन पर रीडायरेक्ट किया गया है. इसमें डोमेन नेम ऐंकर ("||") का इस्तेमाल किया गया है, ताकि example.com से आने वाले किसी भी अनुरोध को रोका जा सके. "transform" में मौजूद "transform" कुंजी से पता चलता है कि सबडोमेन पर रीडायरेक्ट करने के लिए हमेशा "https" का इस्तेमाल किया जाएगा."scheme"

{
  "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"
नेटवर्क अनुरोध, उस फ़्रेम के लिए फ़र्स्ट पार्टी है जिसमें वह शुरू हुआ था.

"thirdParty"
यह नेटवर्क अनुरोध, उस फ़्रेम के लिए तीसरे पक्ष का है जिसमें यह शुरू हुआ था.

ExtensionActionOptions

Chrome 88 या इसके बाद का वर्शन

प्रॉपर्टी

  • displayActionCountAsBadgeText

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

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

  • tabUpdate

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

    Chrome 89 या इसके बाद का वर्शन

    टैब के ऐक्शन की संख्या को कैसे अडजस्ट किया जाना चाहिए, इसकी जानकारी.

GetDisabledRuleIdsOptions

Chrome 111+

प्रॉपर्टी

  • rulesetId

    स्ट्रिंग

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

GetRulesFilter

Chrome 111+

प्रॉपर्टी

  • ruleIds

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

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

HeaderInfo

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

प्रॉपर्टी

  • excludedValues

    string[] ज़रूरी नहीं है

    अगर यह शर्त दी गई है, तो हेडर मौजूद होने पर भी यह शर्त पूरी नहीं होती. हालांकि, इसकी वैल्यू में इस सूची का कम से कम एक एलिमेंट शामिल होना चाहिए. इसमें values के जैसा ही मैच पैटर्न सिंटैक्स इस्तेमाल किया जाता है.

  • हेडर

    स्ट्रिंग

    हेडर का नाम. यह शर्त, नाम से सिर्फ़ तब मेल खाती है, जब values और excludedValues, दोनों को नहीं चुना गया हो.

  • values

    string[] ज़रूरी नहीं है

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

    '*' : यह किसी भी संख्या के वर्णों से मेल खाता है.

    '?' : इससे शून्य या एक वर्ण का मिलान होता है.

    '*' और '?' को बैकस्लैश से एस्केप किया जा सकता है. उदाहरण के लिए, '\*' और '\?'

HeaderOperation

Chrome 86 या इसके बाद का वर्शन

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

Enum

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

"set"
यह कार्रवाई, तय किए गए हेडर के लिए नई वैल्यू सेट करती है. साथ ही, एक ही नाम वाले मौजूदा हेडर हटा देती है.

"remove"
इससे तय किए गए हेडर की सभी एंट्री हट जाती हैं.

IsRegexSupportedResult

Chrome 87 या इसके बाद के वर्शन

प्रॉपर्टी

  • isSupported

    बूलियन

  • वजह

    UnsupportedRegexReason optional

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

MatchedRule

प्रॉपर्टी

  • ruleId

    संख्या

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

  • rulesetId

    स्ट्रिंग

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

MatchedRuleInfo

प्रॉपर्टी

  • नियम

    MatchedRule

  • tabId

    संख्या

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

  • timeStamp

    संख्या

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

MatchedRuleInfoDebug

प्रॉपर्टी

  • CANNOT TRANSLATE

    RequestDetails

    उस अनुरोध के बारे में जानकारी जिसके लिए नियम मैच हुआ है.

  • नियम

    MatchedRule

MatchedRulesFilter

प्रॉपर्टी

  • minTimeStamp

    number ज़रूरी नहीं

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

  • tabId

    number ज़रूरी नहीं

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

ModifyHeaderInfo

Chrome 86 या इसके बाद का वर्शन

प्रॉपर्टी

  • हेडर

    स्ट्रिंग

    बदलाव किए जाने वाले हेडर का नाम.

  • कार्रवाई

    HeaderOperation

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

  • मान

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

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

QueryKeyValue

प्रॉपर्टी

  • बटन

    स्ट्रिंग

  • replaceOnly

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

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

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

  • मान

    स्ट्रिंग

QueryTransform

प्रॉपर्टी

  • addOrReplaceParams

    QueryKeyValue[] optional

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

  • removeParams

    string[] ज़रूरी नहीं है

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

Redirect

प्रॉपर्टी

  • extensionPath

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

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

  • regexSubstitution

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

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

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

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

    यूआरएल में किए जाने वाले ट्रांसफ़ॉर्मेशन.

  • url

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

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

RegexOptions

Chrome 87 या इसके बाद के वर्शन

प्रॉपर्टी

  • isCaseSensitive

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

    regex में दिया गया कॉन्टेंट केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) है या नहीं. यह डिफ़ॉल्ट रूप से 'सही' पर सेट होती है.

  • रेगुलर एक्सप्रेशन

    स्ट्रिंग

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

  • requireCapturing

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

    क्या बताई गई regex को कैप्चर करना ज़रूरी है. रीडायरेक्ट करने के नियमों के लिए ही कैप्चर करना ज़रूरी है. इन नियमों में regexSubstition कार्रवाई के बारे में बताया जाता है. डिफ़ॉल्ट रूप से, यह 'गलत' पर सेट होता है.

RequestDetails

प्रॉपर्टी

  • documentId

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

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

    अगर यह अनुरोध किसी फ़्रेम के लिए है, तो फ़्रेम के दस्तावेज़ के लिए यूनीक आइडेंटिफ़ायर.

  • documentLifecycle

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

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

    अगर यह अनुरोध किसी फ़्रेम के लिए है, तो फ़्रेम के दस्तावेज़ का लाइफ़साइकल.

  • frameId

    संख्या

    वैल्यू 0 से पता चलता है कि अनुरोध मुख्य फ़्रेम में किया गया है. पॉज़िटिव वैल्यू से पता चलता है कि अनुरोध किस सबफ़्रेम में किया गया है. अगर किसी (सब-)फ़्रेम का दस्तावेज़ लोड किया जाता है (type है main_frame या sub_frame), तो frameId इस फ़्रेम का आईडी दिखाता है, न कि आउटर फ़्रेम का आईडी. फ़्रेम आईडी, टैब में यूनीक होते हैं.

  • frameType

    FrameType optional

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

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

  • शुरू करने वाला

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

    वह ऑरिजिन जहां से अनुरोध शुरू किया गया था. रीडाइरेक्ट करने पर, इसमें कोई बदलाव नहीं होता. अगर यह ओपेक ऑरिजिन है, तो 'null' स्ट्रिंग का इस्तेमाल किया जाएगा.

  • तरीका

    स्ट्रिंग

    यह एक स्टैंडर्ड एचटीटीपी मेथड है.

  • parentDocumentId

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

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

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

  • parentFrameId

    संख्या

    उस फ़्रेम का आईडी जिसने अनुरोध भेजा है. अगर कोई पैरंट फ़्रेम मौजूद नहीं है, तो इसे -1 पर सेट करें.

  • requestId

    स्ट्रिंग

    अनुरोध का आईडी. अनुरोध आईडी, ब्राउज़र के किसी सेशन में यूनीक होते हैं.

  • tabId

    संख्या

    उस टैब का आईडी जिसमें अनुरोध किया गया है. अगर अनुरोध किसी टैब से जुड़ा नहीं है, तो इसे -1 पर सेट करें.

  • टाइप

    ResourceType

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

  • url

    स्ट्रिंग

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

RequestMethod

Chrome 91 या इसके बाद के वर्शन

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

Enum

"connect"

"delete"

"get"

"head"

"options"

"patch"

"post"

"put"

"other"

ResourceType

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

Enum

"main_frame"

"sub_frame"

"stylesheet"

"script"

"image"

"font"

"object"

"xmlhttprequest"

"ping"

"csp_report"

"media"

"websocket"

"webtransport"

"webbundle"

"other"

Rule

प्रॉपर्टी

  • ऐक्शन गेम

    RuleAction

    इस नियम के मैच होने पर की जाने वाली कार्रवाई.

  • शर्त

    RuleCondition

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

  • आईडी

    संख्या

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

  • प्राथमिकता

    number ज़रूरी नहीं

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

RuleAction

प्रॉपर्टी

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

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

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

  • requestHeaders

    ModifyHeaderInfo[] optional

    Chrome 86 या इसके बाद का वर्शन

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

  • responseHeaders

    ModifyHeaderInfo[] optional

    Chrome 86 या इसके बाद का वर्शन

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

  • टाइप

    RuleActionType

    कार्रवाई किस तरह की है.

RuleActionType

इससे यह पता चलता है कि अगर कोई RuleCondition मेल खाती है, तो किस तरह की कार्रवाई करनी है.

Enum

"block"
नेटवर्क अनुरोध को ब्लॉक करें.

"redirect"
नेटवर्क अनुरोध को रीडायरेक्ट करता है.

"allow"
नेटवर्क अनुरोध को अनुमति दें. अगर अनुमति देने वाला कोई नियम अनुरोध से मैच करता है, तो अनुरोध को इंटरसेप्ट नहीं किया जाएगा.

"upgradeScheme"
अगर अनुरोध एचटीटीपी या एफ़टीपी है, तो नेटवर्क अनुरोध के यूआरएल की स्कीम को एचटीटीपीएस पर अपग्रेड करें.

"modifyHeaders"
नेटवर्क अनुरोध से अनुरोध/जवाब के हेडर में बदलाव करें.

"allowAllRequests"
फ़्रेम के अनुरोध के साथ-साथ, फ़्रेम के क्रम में मौजूद सभी अनुरोधों को अनुमति दें.

RuleCondition

प्रॉपर्टी

  • domainType

    DomainType optional

    इससे पता चलता है कि नेटवर्क अनुरोध, उस डोमेन के लिए पहले पक्ष का है या तीसरे पक्ष का जिससे वह जनरेट हुआ है. अगर इसे शामिल नहीं किया जाता है, तो सभी अनुरोध स्वीकार कर लिए जाते हैं.

  • डोमेन

    string[] ज़रूरी नहीं है

    Chrome 101 के बाद से काम नहीं करता

    इसके बजाय, initiatorDomains का इस्तेमाल करें

    यह नियम, सिर्फ़ domains की सूची से जनरेट होने वाले नेटवर्क अनुरोधों से मैच करेगा.

  • excludedDomains

    string[] ज़रूरी नहीं है

    Chrome 101 के बाद से काम नहीं करता

    इसके बजाय, excludedInitiatorDomains का इस्तेमाल करें

    यह नियम, excludedDomains की सूची से जनरेट होने वाले नेटवर्क अनुरोधों से मेल नहीं खाएगा.

  • excludedInitiatorDomains

    string[] ज़रूरी नहीं है

    Chrome 101 या इसके बाद के वर्शन

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

    ध्यान दें:

    • "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
    • एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
    • अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
    • यह अनुरोध शुरू करने वाले व्यक्ति से मैच करता है, न कि अनुरोध के यूआरएल से.
    • सूची में शामिल डोमेन के सब-डोमेन को भी बाहर रखा जाता है.
  • excludedRequestDomains

    string[] ज़रूरी नहीं है

    Chrome 101 या इसके बाद के वर्शन

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

    ध्यान दें:

    • "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
    • एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
    • अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
    • सूची में शामिल डोमेन के सब-डोमेन को भी बाहर रखा जाता है.
  • excludedRequestMethods

    RequestMethod[] ज़रूरी नहीं है

    Chrome 91 या इसके बाद के वर्शन

    अनुरोध के उन तरीकों की सूची जिनसे नियम मैच नहीं करेगा. requestMethods और excludedRequestMethods में से सिर्फ़ एक को तय करना है. अगर इनमें से किसी को भी नहीं चुना जाता है, तो अनुरोध के सभी तरीकों को मैच किया जाता है.

  • excludedResourceTypes

    ResourceType[] ज़रूरी नहीं है

    उन संसाधन टाइप की सूची जिनसे यह नियम मैच नहीं करेगा. resourceTypes और excludedResourceTypes में से सिर्फ़ एक को तय करना है. अगर इनमें से किसी भी विकल्प को नहीं चुना जाता है, तो "main_frame" को छोड़कर सभी संसाधन टाइप ब्लॉक कर दिए जाते हैं.

  • excludedResponseHeaders

    HeaderInfo[] optional

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

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

  • excludedTabIds

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

    Chrome 92 या इसके बाद का वर्शन

    tabs.Tab.id की वह सूची जिससे नियम को मैच नहीं करना चाहिए. tabs.TAB_ID_NONE आईडी, उन अनुरोधों को शामिल नहीं करता जो किसी टैब से नहीं किए गए हैं. यह सुविधा सिर्फ़ सेशन के दायरे वाले नियमों के साथ काम करती है.

  • initiatorDomains

    string[] ज़रूरी नहीं है

    Chrome 101 या इसके बाद के वर्शन

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

    ध्यान दें:

    • "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
    • एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
    • अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
    • यह अनुरोध शुरू करने वाले व्यक्ति से मैच करता है, न कि अनुरोध के यूआरएल से.
    • सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
  • isUrlFilterCaseSensitive

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

    urlFilter या regexFilter (जो भी एट्रिब्यूट दिया गया है) केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) है या नहीं. डिफ़ॉल्ट रूप से, यह 'गलत' पर सेट होती है.

  • regexFilter

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

    नेटवर्क अनुरोध के यूआरएल से मेल खाने के लिए रेगुलर एक्सप्रेशन. यह RE2 सिंटैक्स के मुताबिक है.

    ध्यान दें: urlFilter या regexFilter में से सिर्फ़ एक को तय किया जा सकता है.

    ध्यान दें: regexFilter में सिर्फ़ ASCII वर्ण होने चाहिए. इसे ऐसे यूआरएल से मैच किया जाता है जिसमें होस्ट को punycode फ़ॉर्मैट में एन्कोड किया गया हो (अंतरराष्ट्रीय डोमेन के मामले में). साथ ही, किसी भी अन्य नॉन-आस्की वर्ण को यूटीएफ़-8 में यूआरएल एन्कोड किया गया हो.

  • requestDomains

    string[] ज़रूरी नहीं है

    Chrome 101 या इसके बाद के वर्शन

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

    ध्यान दें:

    • "a.example.com" जैसे सब-डोमेन भी इस्तेमाल किए जा सकते हैं.
    • एंट्री में सिर्फ़ ASCII वर्ण होने चाहिए.
    • अंतरराष्ट्रीय डोमेन के लिए, प्यूनीकोड एन्कोडिंग का इस्तेमाल करें.
    • सूची में शामिल डोमेन के सब-डोमेन भी मैच किए जाते हैं.
  • requestMethods

    RequestMethod[] ज़रूरी नहीं है

    Chrome 91 या इसके बाद के वर्शन

    एचटीटीपी अनुरोध के उन तरीकों की सूची जिनसे नियम मैच कर सकता है. खाली लिस्ट की अनुमति नहीं है.

    ध्यान दें: requestMethods नियम की शर्त तय करने पर, एचटीटीपी(एस) के अलावा अन्य अनुरोध भी शामिल नहीं किए जाएंगे. हालांकि, excludedRequestMethods तय करने पर ऐसा नहीं होगा.

  • resourceTypes

    ResourceType[] ज़रूरी नहीं है

    संसाधन टाइप की सूची, जिनसे नियम मैच कर सकता है. खाली लिस्ट की अनुमति नहीं है.

    ध्यान दें: इसे allowAllRequests नियमों के लिए तय करना ज़रूरी है. इसमें सिर्फ़ sub_frame और main_frame संसाधन टाइप शामिल हो सकते हैं.

  • responseHeaders

    HeaderInfo[] optional

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

    अगर अनुरोध, इस सूची में दी गई किसी भी रिस्पॉन्स हेडर की शर्त से मेल खाता है, तो नियम मैच करता है. हालांकि, ऐसा तब होता है, जब शर्त दी गई हो.

  • tabIds

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

    Chrome 92 या इसके बाद का वर्शन

    tabs.Tab.id की वह सूची जिससे नियम मेल खाना चाहिए. tabs.TAB_ID_NONE का आईडी, उन अनुरोधों से मेल खाता है जो किसी टैब से नहीं किए गए हैं. खाली लिस्ट की अनुमति नहीं है. यह सुविधा सिर्फ़ सेशन के दायरे वाले नियमों के साथ काम करती है.

  • urlFilter

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

    यह पैटर्न, नेटवर्क अनुरोध के यूआरएल से मेल खाता है. इस्तेमाल किए जा सकने वाले कंस्ट्रक्ट:

    '*' : वाइल्डकार्ड: यह किसी भी संख्या के वर्णों से मेल खाता है.

    '|' : लेफ्ट/राइट ऐंकर: अगर इसका इस्तेमाल पैटर्न के किसी भी आखिर में किया जाता है, तो यह यूआरएल की शुरुआत/आखिर के बारे में बताता है.

    '||' : डोमेन नेम ऐंकर: अगर इसका इस्तेमाल पैटर्न की शुरुआत में किया जाता है, तो यह यूआरएल के (सब-)डोमेन की शुरुआत के बारे में बताता है.

    '^' : सेपरेटर वर्ण: यह किसी अक्षर, अंक या इनमें से किसी एक के अलावा किसी भी वर्ण से मेल खाता है: _, -, . या %. यह यूआरएल के आखिरी हिस्से से भी मैच करता है.

    इसलिए, urlFilter में ये शामिल होते हैं: (बाईं ओर मौजूद ऐंकर/डोमेन नाम ऐंकर, ज़रूरी नहीं है) + पैटर्न + (दाईं ओर मौजूद ऐंकर, ज़रूरी नहीं है).

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

    ||* से शुरू होने वाले पैटर्न की अनुमति नहीं है. इसके बजाय, * का इस्तेमाल करें.

    ध्यान दें: urlFilter या regexFilter में से सिर्फ़ एक को तय किया जा सकता है.

    ध्यान दें: urlFilter में सिर्फ़ ASCII वर्ण होने चाहिए. इसे ऐसे यूआरएल से मैच किया जाता है जिसमें होस्ट को punycode फ़ॉर्मैट में एन्कोड किया गया हो (अंतरराष्ट्रीय डोमेन के मामले में). साथ ही, किसी भी अन्य नॉन-आस्की वर्ण को यूटीएफ़-8 में यूआरएल एन्कोड किया गया हो. उदाहरण के लिए, जब अनुरोध का यूआरएल http://abc.рф?q=ф होता है, तब urlFilter का मिलान http://abc.xn--p1ai/?q=%D1%84 यूआरएल से किया जाएगा.

Ruleset

प्रॉपर्टी

  • चालू किया गया

    बूलियन

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

  • आईडी

    स्ट्रिंग

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

  • पाथ

    स्ट्रिंग

    एक्सटेंशन डायरेक्ट्री के हिसाब से, JSON फ़ॉर्मैट वाले नियमों के सेट का पाथ.

RulesMatchedDetails

प्रॉपर्टी

  • rulesMatchedInfo

    MatchedRuleInfo[]

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

TabActionCountUpdate

Chrome 89 या इसके बाद का वर्शन

प्रॉपर्टी

  • अधिक

    संख्या

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

  • tabId

    संख्या

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

TestMatchOutcomeResult

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

प्रॉपर्टी

  • matchedRules

    MatchedRule[]

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

TestMatchRequestDetails

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

प्रॉपर्टी

  • शुरू करने वाला

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

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

  • तरीका

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

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

  • responseHeaders

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

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

    अगर अनुरोध को भेजने से पहले ब्लॉक या रीडायरेक्ट नहीं किया जाता है, तो काल्पनिक जवाब से मिले हेडर. इसे एक ऑब्जेक्ट के तौर पर दिखाया जाता है. यह ऑब्जेक्ट, हेडर के नाम को स्ट्रिंग वैल्यू की सूची से मैप करता है. अगर यह तय नहीं किया गया है, तो काल्पनिक जवाब में खाली रिस्पॉन्स हेडर दिखेंगे. ये ऐसे नियमों से मेल खा सकते हैं जो हेडर के मौजूद न होने पर मेल खाते हैं. उदा. {"content-type": ["text/html; charset=utf-8", "multipart/form-data"]}

  • tabId

    number ज़रूरी नहीं

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

  • टाइप

    ResourceType

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

  • url

    स्ट्रिंग

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

UnsupportedRegexReason

Chrome 87 या इसके बाद के वर्शन

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

Enum

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

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

UpdateRuleOptions

Chrome 87 या इसके बाद के वर्शन

प्रॉपर्टी

  • addRules

    Rule[] optional

    जोड़ने के लिए नियम.

  • removeRuleIds

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

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

UpdateRulesetOptions

Chrome 87 या इसके बाद के वर्शन

प्रॉपर्टी

  • disableRulesetIds

    string[] ज़रूरी नहीं है

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

  • enableRulesetIds

    string[] ज़रूरी नहीं है

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

UpdateStaticRulesOptions

Chrome 111+

प्रॉपर्टी

  • disableRuleIds

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

    यह Ruleset में मौजूद उन नियमों के आईडी का सेट है जिन्हें बंद करना है.

  • enableRuleIds

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

    चालू करने के लिए, Ruleset में मौजूद नियमों से जुड़े आईडी का सेट.

  • rulesetId

    स्ट्रिंग

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

URLTransform

प्रॉपर्टी

  • फ़्रैगमेंट

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

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

  • होस्ट

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

    अनुरोध के लिए नया होस्ट.

  • पासवर्ड

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

    अनुरोध के लिए नया पासवर्ड.

  • पाथ

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

    अनुरोध के लिए नया पाथ. अगर यह खाली है, तो मौजूदा पाथ मिट जाता है.

  • पोर्ट

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

    अनुरोध के लिए नया पोर्ट. अगर यह फ़ील्ड खाली है, तो मौजूदा पोर्ट मिट जाएगा.

  • क्वेरी

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

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

  • queryTransform

    QueryTransform optional

    क्वेरी के की-वैल्यू पेयर जोड़ें, हटाएं या बदलें.

  • स्कीम

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

    अनुरोध के लिए नई स्कीम. इन वैल्यू का इस्तेमाल किया जा सकता है: "http", "https", "ftp", और "chrome-extension".

  • उपयोगकर्ता नाम

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

    अनुरोध के लिए नया उपयोगकर्ता नाम.

प्रॉपर्टी

DYNAMIC_RULESET_ID

एक्सटेंशन के ज़रिए जोड़े गए डाइनैमिक नियमों के लिए, नियमों के सेट का आईडी.

मान

"_dynamic"

GETMATCHEDRULES_QUOTA_INTERVAL

यह वह समयावधि होती है जिसमें MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL getMatchedRules कॉल किए जा सकते हैं. इसे मिनटों में दिखाया जाता है. इसके बाद किए जाने वाले कॉल तुरंत फ़ेल हो जाएंगे और runtime.lastError के तौर पर सेट हो जाएंगे. ध्यान दें: उपयोगकर्ता के जेस्चर से जुड़ी getMatchedRules कॉल को कोटे से बाहर रखा गया है.

मान

10

GUARANTEED_MINIMUM_STATIC_RULES

Chrome 89 या इसके बाद का वर्शन

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

मान

30000

MAX_GETMATCHEDRULES_CALLS_PER_INTERVAL

GETMATCHEDRULES_QUOTA_INTERVAL की अवधि में getMatchedRules को इतनी बार कॉल किया जा सकता है.

मान

20

MAX_NUMBER_OF_DYNAMIC_RULES

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

मान

30000

MAX_NUMBER_OF_ENABLED_STATIC_RULESETS

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

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

मान

50

MAX_NUMBER_OF_REGEX_RULES

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

मान

1000

MAX_NUMBER_OF_SESSION_RULES

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

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

मान

5000

MAX_NUMBER_OF_STATIC_RULESETS

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

मान

100

MAX_NUMBER_OF_UNSAFE_DYNAMIC_RULES

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

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

मान

5000

MAX_NUMBER_OF_UNSAFE_SESSION_RULES

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

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

मान

5000

SESSION_RULESET_ID

Chrome 90+

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

मान

"_session"

तरीके

getAvailableStaticRuleCount()

Chrome 89 या इसके बाद का वर्शन 
chrome.declarativeNetRequest.getAvailableStaticRuleCount(): Promise<number>

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

रिटर्न

  • Promise<number>

    Chrome 91 या इसके बाद के वर्शन

getDisabledRuleIds()

Chrome 111+ 
chrome.declarativeNetRequest.getDisabledRuleIds(
  options: GetDisabledRuleIdsOptions,
): Promise<number[]>

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

पैरामीटर

  • विकल्प

    GetDisabledRuleIdsOptions

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

रिटर्न

  • Promise<number[]>

getDynamicRules()

chrome.declarativeNetRequest.getDynamicRules(
  filter?: GetRulesFilter,
): Promise<Rule[]>

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

पैरामीटर

  • फ़िल्टर करें

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

    Chrome 111+

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

रिटर्न

  • Promise<Rule[]>

    Chrome 91 या इसके बाद के वर्शन

getEnabledRulesets()

chrome.declarativeNetRequest.getEnabledRulesets(): Promise<string[]>

चालू किए गए स्टैटिक नियमों के मौजूदा सेट के आईडी दिखाता है.

रिटर्न

  • Promise<string[]>

    Chrome 91 या इसके बाद के वर्शन

getMatchedRules()

chrome.declarativeNetRequest.getMatchedRules(
  filter?: MatchedRulesFilter,
): Promise<RulesMatchedDetails>

यह एक्सटेंशन से मेल खाने वाले सभी नियमों को दिखाता है. कॉल करने वाले लोग, मैच किए गए नियमों की सूची को फ़िल्टर कर सकते हैं. इसके लिए, उन्हें filter तय करना होगा. यह तरीका सिर्फ़ उन एक्सटेंशन के लिए उपलब्ध है जिनके पास "declarativeNetRequestFeedback" की अनुमति है या जिन्हें filter में बताए गए tabId के लिए "activeTab" की अनुमति दी गई है. ध्यान दें: ऐसे नियम नहीं दिखाए जाएंगे जो किसी चालू दस्तावेज़ से जुड़े नहीं हैं और जिनका मिलान पांच मिनट से ज़्यादा समय पहले हुआ था.

पैरामीटर

  • फ़िल्टर करें

    MatchedRulesFilter optional

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

रिटर्न

getSessionRules()

Chrome 90+ 
chrome.declarativeNetRequest.getSessionRules(
  filter?: GetRulesFilter,
): Promise<Rule[]>

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

पैरामीटर

  • फ़िल्टर करें

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

    Chrome 111+

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

रिटर्न

  • Promise<Rule[]>

    Chrome 91 या इसके बाद के वर्शन

isRegexSupported()

Chrome 87 या इसके बाद के वर्शन 
chrome.declarativeNetRequest.isRegexSupported(
  regexOptions: RegexOptions,
): Promise<IsRegexSupportedResult>

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

पैरामीटर

  • regexOptions

    RegexOptions

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

रिटर्न

setExtensionActionOptions()

Chrome 88 या इसके बाद का वर्शन 
chrome.declarativeNetRequest.setExtensionActionOptions(
  options: ExtensionActionOptions,
): Promise<void>

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

पैरामीटर

रिटर्न

  • Promise<void>

    Chrome 91 या इसके बाद के वर्शन

testMatchOutcome()

Chrome 103 और इसके बाद के वर्शन 
chrome.declarativeNetRequest.testMatchOutcome(
  request: TestMatchRequestDetails,
): Promise<TestMatchOutcomeResult>

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

पैरामीटर

रिटर्न

updateDynamicRules()

chrome.declarativeNetRequest.updateDynamicRules(
  options: UpdateRuleOptions,
): Promise<void>

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

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

पैरामीटर

  • विकल्प

    UpdateRuleOptions

    Chrome 87 या इसके बाद के वर्शन

रिटर्न

  • Promise<void>

    Chrome 91 या इसके बाद के वर्शन

updateEnabledRulesets()

chrome.declarativeNetRequest.updateEnabledRulesets(
  options: UpdateRulesetOptions,
): Promise<void>

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

पैरामीटर

  • विकल्प

    UpdateRulesetOptions

    Chrome 87 या इसके बाद के वर्शन

रिटर्न

  • Promise<void>

    Chrome 91 या इसके बाद के वर्शन

updateSessionRules()

Chrome 90+ 
chrome.declarativeNetRequest.updateSessionRules(
  options: UpdateRuleOptions,
): Promise<void>

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

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

पैरामीटर

रिटर्न

  • Promise<void>

    Chrome 91 या इसके बाद के वर्शन

updateStaticRules()

Chrome 111+ 
chrome.declarativeNetRequest.updateStaticRules(
  options: UpdateStaticRulesOptions,
): Promise<void>

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

पैरामीटर

रिटर्न

  • Promise<void>

इवेंट

onRuleMatchedDebug

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

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

पैरामीटर