जिन यूआरएल को अनुमति मिली है उनकी सूची

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

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

अगर आपकी स्क्रिप्ट या ऐड-ऑन ये कार्रवाइयां करता है, तो अनुमति वाले डोमेन की सूची का इस्तेमाल किया जाता है:

  • Apps Script UrlFetch सेवा का इस्तेमाल करके, किसी बाहरी जगह (जैसे कि एचटीटीपीएस एंडपॉइंट) से जानकारी फ़ेच या फ़ेच करता है. अनुमति वाली सूची में शामिल यूआरएल को फ़ेच करने के लिए, अपनी मेनिफ़ेस्ट फ़ाइल में urlFetchWhitelist फ़ील्ड शामिल करें.
  • उपयोगकर्ता की कार्रवाई के जवाब में, यूआरएल खोलता या दिखाता है. यह Google Workspace के ऐड-ऑन के लिए ज़रूरी है, जो Google के बाहर के यूआरएल खोलते हैं या दिखाते हैं. अनुमति वाली सूची में शामिल यूआरएल को खोलने के लिए, अपनी मेनिफ़ेस्ट फ़ाइल में addOns.common.openLinkUrlPrefixes फ़ील्ड को शामिल करें.

अनुमति वाली सूची में प्रीफ़िक्स जोड़ना

अपनी मेनिफ़ेस्ट फ़ाइल में, addOns.common.openLinkUrlPrefixes या urlFetchWhitelist फ़ील्ड को शामिल करके, अनुमति वाले डोमेन की सूची तय करते समय, आपको यूआरएल प्रीफ़िक्स की सूची शामिल करनी होगी. मेनिफ़ेस्ट में जोड़े गए प्रीफ़िक्स को इन शर्तों के मुताबिक होना चाहिए:

  • हर प्रीफ़िक्स एक मान्य यूआरएल होना चाहिए.
  • हर प्रीफ़िक्स में https:// का इस्तेमाल होना चाहिए, http:// का नहीं.
  • हर प्रीफ़िक्स का एक पूरा डोमेन होना चाहिए.
  • हर प्रीफ़िक्स में कोई खाली पाथ नहीं होना चाहिए. उदाहरण के लिए, https://www.google.com/ मान्य है, लेकिन https://www.google.com नहीं.
  • यूआरएल सबडोमेन प्रीफ़िक्स से मैच करने के लिए, वाइल्डकार्ड का इस्तेमाल किया जा सकता है.
  • सभी लिंक से मैच करने के लिए, addOns.common.openLinkUrlPrefixes फ़ील्ड में एक * वाइल्डकार्ड का इस्तेमाल किया जा सकता है. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता, क्योंकि इससे उपयोगकर्ता का डेटा खतरे में पड़ सकता है और ऐड-ऑन की समीक्षा की प्रोसेस ज़्यादा समय तक चल सकती है. वाइल्डकार्ड का इस्तेमाल सिर्फ़ तब करें, जब ऐड-ऑन के फ़ंक्शन के लिए इसकी ज़रूरत हो.

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

  • पाथ मैचिंग, केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) होती है.
  • अगर प्रीफ़िक्स, यूआरएल से मेल खाता है, तो यह एक मैच होता है.
  • अगर यूआरएल वही है या प्रीफ़िक्स का चाइल्ड है, तो यह एक मैच होता है.

उदाहरण के लिए, प्रीफ़िक्स https://example.com/foo इन यूआरएल से मेल खाता है:

  • https://example.com/foo
  • https://example.com/foo/
  • https://example.com/foo/bar
  • https://example.com/foo?bar
  • https://example.com/foo#bar

वाइल्डकार्ड का इस्तेमाल करना

urlFetchWhitelist और addOns.common.openLinkUrlPrefixes, दोनों फ़ील्ड के सबडोमेन से मैच करने के लिए, किसी एक वाइल्डकार्ड वर्ण (*) का इस्तेमाल किया जा सकता है. एक से ज़्यादा सबडोमेन से मैच करने के लिए, एक से ज़्यादा वाइल्डकार्ड का इस्तेमाल नहीं किया जा सकता. साथ ही, वाइल्डकार्ड में यूआरएल का शुरुआती प्रीफ़िक्स दिखना चाहिए.

उदाहरण के लिए, प्रीफ़िक्स https://*.example.com/foo इन यूआरएल से मेल खाता है:

  • https://subdomain.example.com/foo
  • https://any.number.of.subdomains.example.com/foo

प्रीफ़िक्स https://*.example.com/foo इन यूआरएल से मेल नहीं खाता:

  • https://subdomain.example.com/bar (सफ़िक्स मेल नहीं खाता)
  • https://example.com/foo (कम से कम एक सबडोमेन मौजूद होना चाहिए)

जब मेनिफ़ेस्ट को सेव करने की कोशिश की जाती है, तो प्रीफ़िक्स के कुछ नियम लागू होते हैं. उदाहरण के लिए, अगर सेव करने की कोशिश करते समय ये प्रीफ़िक्स आपके मेनिफ़ेस्ट में मौजूद हैं, तो गड़बड़ी की वजह बनती है:

  • https://*.*.example.com/foo (एक से ज़्यादा वाइल्डकार्ड इस्तेमाल नहीं किए जा सकते हैं)
  • https://subdomain.*.example.com/foo (वाइल्डकार्ड को शुरू होने वाले प्रीफ़िक्स के तौर पर इस्तेमाल किया जाना चाहिए)