مهال ویش شوې دنده یا د انسان ننوتل: API باید کوم هویت وویني؟
د cron دنده او د ننوتلو په غوښتنه کې ولاړ سړی بېل بېل اصلي برخې دي. د اتومات کولو دمخه د شبکې لاره، د اپلیکیشن هویت او استازیتوب پرتله کړئ.
مهال ویش شوې دنده او د ننوتلو په غوښتنه کې ولاړ سړی یو شان API ته په بېلو اعتبار نامو، بېل عمر او بېلو مالکانو سره زنګ وهي۔ دندې ته د شبکې لاره، د اپلیکیشن هویت او د اجازو ټولګه ورته اړ ده؛ سړي ته ننوتل، دویم عامل او ناسته ورته اړ ده۔ دواړه سره ګډول داسې اتومات جوړوي چې هر کله د سړي پټنوم بدل شي ماته شي، یا داسې څو عامله تګلاره چې یوازې دومره کمزورې شوې چې د cron دنده ژوندۍ پاتې شي۔
درې دروازې چې د یوې په څېر ښکاري
د سرچینې پتې قاعده پوښتنه کوي چې غوښتنه له کومه راغله۔ تصدیق پوښتنه کوي چې څوک زنګ وهي او کوم شواهد وړاندې شول۔ اجازه پوښتنه کوي چې ایا دا اصلي برخه دا عملیه کولی شي۔ VPN یوازې له درېیو لومړی بدلوي، او هغه هم د دندې لپاره نه بلکې په هوسټ کې د هر بهیر لپاره بدلوي، نو په پېښې ریکارډ کې درې کتنې جلا وساتئ۔
همدا لامل دی چې د وتلو نود بدلول د سرچینې پتې له امله رد اصلاح کولی شي او ناسم ټوکن بې لاسه پرېږدي۔ همدا لامل دی چې سم API ټوکن هم د هغې دندې څخه چې هلته لاره نه لري خصوصي پای ټکی د لاسرسي وړ نه جوړوي۔
تعاملي لاره د اتومات کولو لپاره بده بڼه ده
د سړي ننوتل په سکریپټ کې لیکل زړه ښه کوونکي دي ځکه چې یو ځل کار کوي۔ سکریپټ پټنوم، شاید د یو ځلي پټنوم تخم ساتي، او بیا د هغې ننګونې پورې تړلی وي چې د انسان غوښتنې لپاره جوړه شوې۔ د OAuth لپاره اوسنی غوره امنیتي عمل، RFC 9700، د resource-owner-password-credentials مرستې بندیز لګوي او څرګندوي چې ولې د دوو عاملونو او څو مرحلو تصدیق سره بد ځای لري۔
موندل شوې بدیله معمولاً د پټ پیرودونکي بهیر دی چې پکې د اجازې سرور اپلیکیشن تصدیقوي او ټوکن صادروي۔ په RFC 6749 کې د 4.4 برخې client-credentials مرسته یوه بېلګه ده۔ د هغې شتون نه معنی لري چې هر API یې مني، او نه دا چې د کاروونکي له خوا استازیتوب شوې دنده پرې بدلېدلی شي، ځکه هغه پوښتنې د خدمت مالک ته دي۔ کله چې کوډ لیکئ، لومړی وپوښتئ چې خدمت کومه بې څارنې بڼه ملاتړ کوي۔
VPN لا هم چېرې ځای لري
VPN کولی شي هغه شبکه لاره برابره کړي چې خصوصي API ته اړ ده، او دا قانوني رول دی۔ دا دنده د اپلیکیشن پر وړاندې تصدیق نه کوي، او نه ټاکي چې دنده څه کولی شي۔ شریکه وتلې پته هم دنده نه بلکې هوسټ پېژني، نو د هغې پتې لپاره په اجازه لړلیک کې ننوتنه هر هغه بهیر تېروي چې پر هغې ګرځي۔
که دنده په شریک رنر کې ګرځي، دا توپیر لږ نه بلکې ډېر مهم دی۔ په هماغه هوسټ کې بله کاري بهیر لاره او پته په میراث اخلي، او API نشي کولی دواړه بېل کړي۔ دا هماغه کمزوري ده لکه شریک پټنوم، یوه طبقه ښکته رالېږل شوې۔ محدودیت هلته کېږدئ چې اپلیکیشن یې پلي کولی شي، او که اجازه لړلیک نور تنګ نه شئ کولی، رنر جلا کړئ۔
دواړه ډیزاینونه په رښتینولي سره پرتله کړئ
د انسان ننوتل تاسو ته ریښتینی سړی، ریښتینی دویم عامل او د پلټنې وړ ناسته درکوي، او بې څارنې نشي ګرځېدلی۔ د اپلیکیشن هویت تاسو ته بې څارنې ترسره کول، د بیاکتنې وړ حد او د څرخېدو وړ اعتبار درکوي، او د هغه کاروونکي په استازیتوب نشي کولی چې هېڅ یې استازیتوب نه دی کړی۔ دواړه د یو بل کمزورې نسخه نه ده؛ دوی بېلو پوښتنو ته ځواب وایي۔ د دې پوښتنې سره غوره کړئ چې دنده باید بې له چا ګرځي که نه، او عملیه باید یو ځانګړي کاروونکي ته منسوبه شي که نه۔
که دواړه ځوابونه هو وي، ډیزاین ته پور شوی پټنوم نه بلکې استازیتوب بڼه ورته اړ ده۔ هغه پرېکړه هلته ولیکئ چې بل ساتونکی یې ومومي۔
د سپارلو دمخه څه تایید کړئ
له ریښتیني کارګر څخه یوه اجازه شوې عملیه او یو لازم رد چل کړئ، او دواړه پایلې وساتئ۔ بیا پای ته رسېدلې اعتبار نامه او هغه چلند وازموئ چې کله شبکه لاره نه وي، ځکه دا هغه دوه ناکامۍ دي چې شپه کې یو څوک ویښوي۔
curl -sS -o /dev/null -w '%{http_code}\n' \
-H "Authorization: Bearer TOKEN" https://api.example.com/v1/records
اصلي برخه، حد، د څرخېدو مالک او د ترسره کولو چاپېریال د هغې پایلې ترڅنګ ولیکئ۔ همدا ریکارډ دی چې بله څرخېدنه د پېښې پر ځای معمول ګرځوي۔ دا هماغه برخه ده چې پلټونکی یې غواړي۔