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

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

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

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

  • 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 (वाइल्डकार्ड का इस्तेमाल सबसे पहले प्रीफ़िक्स के तौर पर किया जाना चाहिए)