Apps Script ले VPN मार्फत तपाईंको आन्तरिक एपमा किन पुग्न सक्दैन

ल्यापटपको ब्राउजरमा ड्यासबोर्ड राम्ररी खुल्छ, तर त्यही स्प्रेडसिट स्क्रिप्ट ठेगाना उपलब्ध नभएको त्रुटिसँग असफल हुन्छ। VPN खोल्ने वा बन्द गर्नेले केही फरक पार्दैन, किनकि अनुरोध ल्यापटपबाटै बाहिर जाँदैन। Apps Script Google को पूर्वाधारमा चल्छ र त्यहींबाट आफ्नै जडान खोल्छ। त्यो एउटै तथ्यले सम्पूर्ण डिजाइन निर्धारण गर्छ।

केही परिवर्तन गर्नुअघि दुई प्रश्न छुट्याउनुहोस्: कुन मेसिनले अनुरोध पठाउँछ, र प्राप्तकर्ताले कुन प्रमाणपत्र स्वीकार गर्छ।

अनुरोध कहिल्यै तपाईंको ल्यापटपमा सुरु हुँदैन

ब्राउजर ट्याबले ल्यापटपबाट, VPN एडाप्टर, आन्तरिक DNS प्रत्यय हुँदै निजी सबनेटमा पठाउँछ। UrlFetchApp Google ले व्यवस्थापन गर्ने होस्टबाट पठाउँछ, त्यसैले यसले Google का रिजोल्भर, Google का निकास ठेगाना देख्छ र तपाईंका स्प्लिट-टनेल मार्गमध्ये एउटा पनि देख्दैन। दुवै मार्गले एउटै स्प्रेडसिट कागजात साझा गर्छन्, सञ्जाल स्थान होइन। एपको पहुँच लगमा स्क्रिप्टको प्रयास VPN पूलको ठेगानाको रूपमा होइन, Google ठेगानाको रूपमा देखिन्छ, र यही तपाईंले पाउने सबैभन्दा छिटो पुष्टि हो।

त्यसैले स्थानीय सुधारले केही गर्दैन। ल्यापटपलाई अर्को रिजोल्भरतिर देखाउनु, VPN क्लाइन्ट पुनः सुरु गर्नु वा hosts मा प्रविष्टि थप्नु ब्राउजरको मार्ग बदल्छ र स्क्रिप्टको मार्ग अघि जस्तै छोड्छ।

यसले के बहिष्कृत गर्छ

केवल आन्तरिक अन्त्यबिन्दुमा Apps Script बाट पुग्न सकिँदैन, र यो स्थानमा IP अनुमति सूची पहुँच नियन्त्रणको कमजोर विकल्प हो। Google का निकास दायराहरू फराकिला छन्, अरू ग्राहकसँग साझा छन् र एउटै स्क्रिप्टमा बाँध्न असम्भव छ। UrlFetchApp सन्दर्भ भन्छ कि अनुरोधहरू Google को IP पूलबाट आउँछन्, जुन त्यो दाबीको आधिकारिक संस्करण हो। आन्तरिक एपलाई ती दायराहरूका लागि खोल्दा तपाईंले आरोपित गर्न नसक्ने ट्राफिक भित्र पस्छ।

ब्राउजर सत्रहरू पनि त्यसै गरी व्यवहार गर्छन्। ल्यापटपको ब्राउजरमा भएको कुकी वा SSO सत्र अनुरोधसँग जाँदैन, किनकि अनुरोध सत्र अवस्था नभएको नयाँ HTTPS क्लाइन्ट हो। ब्राउजर SSO पुनर्निर्देशनमा निर्भर जुनसुकै कुरा तपाईंको डाटामा होइन, त्यही पुनर्निर्देशनमा टुंगिन्छ।

दुई व्यावहारिक रूप

पहिलो रूपले स्क्रिप्टलाई स्वीकृत API दिन्छ। आन्तरिक सेवालाई कल गर्नेको प्रमाणीकरण गर्ने गेटवेपछाडि प्रकाशित गर्नुहोस्, त्यसपछि स्क्रिप्टले गेटवेले स्वीकार गर्ने प्रमाणपत्र, जस्तै सेवा खाताको टोकन, प्रस्तुत गरोस्। Apps Script मा यसको अर्थ OAuth2 लाइब्रेरी वा ScriptApp.getOAuthToken() हो, साथै API पक्षमा IP सूचीको सट्टा कल गर्ने पहिचानको अनुमति सूची।

दोस्रो रूपले दिशा उल्टाउँछ। आन्तरिक कार्यले निजी प्रणालीलाई सोध्छ र नियन्त्रित नतिजा स्क्रिप्टले पढ्ने Sheet, Cloud Storage वस्तु वा BigQuery तालिकामा प्रकाशित गर्छ। Cloud Run कार्य, स्थानीय तालिकाकार वा विद्यमान ETL चरण ती कार्य हुन सक्छन्, र तीमध्ये कसैले पनि आगमन जडान स्वीकार गर्नु पर्दैन। त्यसपछि स्प्रेडसिटले इन्टरफेसको सट्टा डाटासेट उपभोग गर्छ।

कुन रूप जित्छ भन्ने ताजगी, फिल्ड-स्तरीय नियन्त्रण र पाठकको अडिट कसले गर्न सक्ने भन्नेमा निर्भर गर्छ।

प्रकाशित नतिजामा के हुनुपर्छ

उल्टो दिशाको फिडलाई स्पष्ट करार चाहिन्छ: यसले बोक्ने फिल्ड, रिफ्रेस अन्तराल, पाठक समूह र आन्तरिक कार्य असफल हुँदा के हुन्छ। ती चार नभई स्प्रेडसिटले चुपचाप हिजोको अंक देखाउँछ। उत्पन्न टाइमस्ट्याम्प स्तम्भ र पङ्क्ति गणना थप्नुहोस्, ताकि पुरानो वा आंशिक प्रकाशन कसैले लग नखोली स्प्रेडसिटमै देखियोस्।

API दिशालाई पनि करार चाहिन्छ: गेटवेले कुन प्रमाणपत्र स्वीकार गर्छ, टोकनले कुन scopes बोक्छ र कुन कल गर्ने पहिचानलाई अनुमति छ। साइन-इन पृष्ठ भएको 200 प्रतिक्रिया सफल कल होइन, त्यसैले स्थिति कोड मात्र होइन, बडी पनि जाँच्नुहोस्।

त्रुटि सही पक्षबाट पढ्नुहोस्

Apps Script ले पुग्न नसकिने होस्टलाई ठेगाना उपलब्ध नभएको अपवादका रूपमा रिपोर्ट गर्छ, जुन ब्राउजरको जडान अस्वीकार सन्देश होइन। गेटवेबाट 403 भन्नुको अर्थ अनुरोध पुग्यो र प्रमाणपत्र वा नीति अस्वीकार भयो। HTML साइन-इन पृष्ठ भन्नुको अर्थ अनुरोध स्क्रिप्टले पूरा गर्न नसक्ने अन्तरक्रियात्मक तहसम्म पुग्यो। तीन फरक असफलता, तीन फरक जिम्मेवार।

स्क्रिप्टको लग ब्राउजरको नतिजाको छेउमा राख्नुहोस्, एउटालाई अर्कोले नबदल्नुहोस्। त्यसपछि बाँकी प्रश्न सामान्य एकीकरण निर्णय हो: त्यो वातावरणलाई आवश्यक पहुँच दिनुहोस्, वा त्यसलाई नियन्त्रित नतिजा पुर्याउनुहोस्।