کیوں Apps Script VPN کے ذریعے آپ کی اندرونی ایپ تک نہیں پہنچ سکتا

ڈیش بورڈ لیپ ٹاپ کے براؤزر میں ٹھیک کھلتا ہے، لیکن وہی اسپریڈ شیٹ اسکرپٹ پتہ دستیاب نہ ہونے کی غلطی سے ناکام ہوتا ہے۔ VPN آن یا آف کرنے سے کچھ نہیں بدلتا، کیونکہ درخواست لیپ ٹاپ سے ہی باہر نہیں نکلتی۔ Apps Script Google کے بنیادی ڈھانچے پر چلتا ہے اور وہیں سے اپنا رابطہ کھولتا ہے۔ یہی ایک حقیقت پورا ڈیزائن طے کرتی ہے۔

کچھ بھی بدلنے سے پہلے دو سوال الگ کریں: کون سی مشین درخواست بھیجتی ہے، اور وصول کرنے والا کون سی اسناد قبول کرتا ہے۔

درخواست کبھی آپ کے لیپ ٹاپ پر شروع نہیں ہوتی

براؤزر کا ٹیب لیپ ٹاپ سے، VPN اڈاپٹر، اندرونی DNS لاحقے سے ہوتا ہوا نجی سب نیٹ میں بھیجتا ہے۔ UrlFetchApp Google کے زیرِ انتظام میزبان سے بھیجتا ہے، اس لیے یہ Google کے حل کنندگان، Google کے اخراجی پتے دیکھتا ہے اور آپ کے split-tunnel راستوں میں سے کوئی ایک بھی نہیں دیکھتا۔ دونوں راستے ایک اسپریڈ شیٹ دستاویز شیئر کرتے ہیں، نیٹ ورک کا مقام نہیں۔ ایپ کے رسائی لاگ میں اسکرپٹ کی کوشش 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 سائن اِن صفحہ کا مطلب ہے کہ درخواست ایسی متعامل تہہ تک پہنچی جو اسکرپٹ مکمل نہیں کر سکتا۔ تین مختلف ناکامیاں، تین مختلف ذمہ دار۔

اسکرپٹ کا لاگ براؤزر کے نتیجے کے ساتھ رکھیں، ایک کو دوسرے سے نہ بدلیں۔ پھر باقی سوال عام انضمام کا فیصلہ ہے: اُس ماحول کو ضروری رسائی دیں، یا اُسے کنٹرول شدہ نتیجہ پہنچائیں۔