ولې 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 د ننوتلو پاڼه مانا دا ده چې غوښتنه هغه متقابل پوړ ته ورسیده چې سکریپټ یې بشپړولای نه شي. درې بېلې ناکامۍ له دریو بېلو مسؤلینو سره.

د سکریپټ لاګ د براوزر د پایلې ترڅنګ وساتئ، نه یو د بل په بدل کې. بیا پاتې پوښتنه عادي یوځای کولو پرېکړه ده: هغه چاپېریال ته اړین لاسرسی ورکړئ، یا ورته کنټرول شوې پایله ورسوئ.