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 साइन-इन पृष्ठ म्हणजे विनंती स्क्रिप्ट पूर्ण करू शकत नाही अशा परस्परसंवादी स्तरापर्यंत पोहोचली. तीन वेगळ्या अयशस्वी घटना, तीन वेगळे जबाबदार.

स्क्रिप्टचा लॉग ब्राउझरच्या निकालाच्या शेजारी ठेवा, एकाची जागा दुसऱ्याने घेऊ नका. मग उरलेला प्रश्न सामान्य एकत्रीकरणाचा निर्णय आहे: त्या वातावरणाला आवश्यक प्रवेश द्या, किंवा त्याला नियंत्रित निकाल पोहोचवा.