షెడ్యూల్ చేసిన పని లేదా మానవ లాగిన్: API ఏ గుర్తింపును చూడాలి?

షెడ్యూల్ చేసిన పని మరియు లాగిన్ ప్రాంప్ట్లో నిలబడిన వ్యక్తి ఒకే APIని వేర్వేరు ఆధారాలు, వేర్వేరు ఆయుష్షు మరియు వేర్వేరు యజమానులతో పిలుస్తారు. పనికి నెట్వర్క్ మార్గం, అప్లికేషన్ గుర్తింపు మరియు అనుమతుల సమితి అవసరం; వ్యక్తికి లాగిన్, రెండవ కారకం మరియు సెషన్ అవసరం. రెండింటినీ కలిపితే వ్యక్తి పాస్వర్డ్ మారిన ప్రతిసారీ విరిగిపోయే ఆటోమేషన్, లేదా cron పనిని సజీవంగా ఉంచడానికి సరిపడా బలహీనపరిచిన బహుళ-కారక విధానం ఏర్పడుతుంది.

ఒకటిలా కనిపించే మూడు ద్వారాలు

మూల చిరునామా నియమం అభ్యర్థన ఎక్కడ నుండి వచ్చిందో అడుగుతుంది. ప్రామాణీకరణ ఎవరు పిలుస్తున్నారు మరియు ఏ రుజువులు సమర్పించబడ్డాయో అడుగుతుంది. అధికారం ఈ ప్రిన్సిపాల్ ఈ చర్యను చేయగలదా అని అడుగుతుంది. VPN మూడింటిలో మొదటిదాన్ని మాత్రమే మారుస్తుంది, దాన్ని కూడా పనికి మాత్రమే కాకుండా హోస్ట్పై నడిచే ప్రతి ప్రక్రియకు మారుస్తుంది, కాబట్టి సంఘటన రికార్డులో మూడు పరిశీలనలను వేరుగా ఉంచండి.

అందుకే నిష్క్రమణ నోడ్ మార్చడం మూల చిరునామా కారణంగా వచ్చిన తిరస్కరణను సరిచేసి, చెల్లని టోకెన్ను తాకకుండా విడిచిపెట్టగలదు. అందుకే చెల్లుబాటు అయ్యే API టోకెన్ ఉన్నా అక్కడికి మార్గం లేని పని నుండి ప్రైవేట్ ఎండ్పాయింట్ను చేరుకోలేరు.

పరస్పర చర్య మార్గం ఆటోమేషన్కు చెడు టెంప్లేట్

వ్యక్తి లాగిన్ను స్క్రిప్ట్ చేయడం ఆకర్షణీయం ఎందుకంటే అది ఒకసారి పనిచేస్తుంది. స్క్రిప్ట్ పాస్వర్డ్, బహుశా ఒక్కసారి-పాస్వర్డ్ విత్తనాన్ని నిల్వ చేసి, తర్వాత మనిషిని కోరేలా రూపొందించిన సవాలుపై ఆధారపడుతుంది. OAuth కోసం ప్రస్తుత ఉత్తమ భద్రతా పద్ధతి, RFC 9700, resource-owner-password-credentials అనుమతిని నిషేధిస్తుంది మరియు అది రెండు-కారక మరియు బహుళ-దశల ప్రామాణీకరణతో ఎందుకు చెడుగా సరిపోతుందో వివరిస్తుంది.

మద్దతు ఉన్న ప్రత్యామ్నాయం సాధారణంగా గోప్య-క్లయింట్ ప్రవాహం, అందులో అధికార సర్వర్ అప్లికేషన్ను ప్రామాణీకరించి టోకెన్ను జారీ చేస్తుంది. RFC 6749 యొక్క 4.4 విభాగంలోని client-credentials అనుమతి దానికి ఒక ఉదాహరణ. దాని ఉనికి ప్రతి API దాన్ని అంగీకరిస్తుందని లేదా వినియోగదారు ప్రతినిధ్యం ఇచ్చిన పనిని దానితో భర్తీ చేయవచ్చని అర్థం కాదు, ఎందుకంటే అవి సేవా యజమానికి ఉన్న ప్రశ్నలు. కోడ్ రాసే ముందు సేవ ఏ పర్యవేక్షణ-రహిత నమూనాకు మద్దతు ఇస్తుందో అడగండి.

VPN ఇప్పటికీ ఎక్కడ సరిపోతుంది

ప్రైవేట్ APIకి అవసరమైన నెట్వర్క్ మార్గాన్ని VPN అందించగలదు, అది చట్టబద్ధమైన పాత్ర. అది పనిని అప్లికేషన్కు ప్రామాణీకరించదు, పని ఏమి చేయగలదో పరిమితి పెట్టదు. పంచుకున్న నిష్క్రమణ చిరునామా పనిని కాదు, హోస్ట్ను గుర్తిస్తుంది, కాబట్టి ఆ చిరునామా కోసం అనుమతి జాబితా నమోదు దానిపై నడిచే ప్రతి ప్రక్రియను అనుమతిస్తుంది.

పని పంచుకున్న రన్నర్పై నడిస్తే, ఆ భేదం తక్కువ కాదు, ఎక్కువ ముఖ్యం. అదే హోస్ట్పై మరో వర్క్ఫ్లో మార్గాన్ని, చిరునామాను వారసత్వంగా పొందుతుంది, API రెండింటినీ వేరు చేయలేదు. ఇది పంచుకున్న పాస్వర్డ్ వలె అదే బలహీనత, ఒక పొర కిందకు జరిపినది. నియంత్రణను అప్లికేషన్ అమలు చేయగల చోట ఉంచండి, అనుమతి జాబితాను మరింత సన్నగా చేయలేకపోతే రన్నర్ను వేరు చేయండి.

రెండు డిజైన్లను నిజాయితీగా పోల్చండి

మానవ లాగిన్ మీకు నిజమైన వ్యక్తిని, నిజమైన రెండవ కారకాన్ని మరియు ఆడిట్ చేయగల సెషన్ను ఇస్తుంది, అది పర్యవేక్షణ లేకుండా నడవదు. అప్లికేషన్ గుర్తింపు మీకు పర్యవేక్షణ-రహిత అమలును, సమీక్షించగల పరిధిని మరియు తిప్పగల ఆధారాన్ని ఇస్తుంది, అది ఏమీ ప్రతినిధ్యం ఇవ్వని వినియోగదారు తరఫున పని చేయలేదు. ఏదీ మరొకదాని బలహీన సంస్కరణ కాదు; అవి వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. పని ఎవరూ లేకుండా నడవాలా మరియు చర్య నిర్దిష్ట వినియోగదారుకు ఆపాదించబడాలా అని అడిగి ఎంచుకోండి.

రెండు సమాధానాలు అవును అయితే, డిజైన్కు అప్పు తీసుకున్న పాస్వర్డ్ కాదు, ప్రతినిధ్య నమూనా అవసరం. ఆ నిర్ణయాన్ని తదుపరి నిర్వాహకుడు కనుగొనే చోట రాయండి.

అప్పగించే ముందు ఏమి ధృవీకరించాలి

నిజమైన వర్కర్ నుండి ఒక అనుమతించిన చర్యను మరియు ఒక తప్పనిసరి తిరస్కరణను నడిపి, రెండు ఫలితాలను ఉంచండి. తర్వాత గడువు ముగిసిన ఆధారాన్ని మరియు నెట్వర్క్ మార్గం అందుబాటులో లేనప్పుడు ప్రవర్తనను పరీక్షించండి, ఎందుకంటే రాత్రిపూట ఎవరినైనా నిద్రలేపేది ఆ రెండు వైఫల్యాలే.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

ప్రిన్సిపాల్, పరిధి, తిప్పే యజమాని మరియు అమలు వాతావరణాన్ని ఆ ఫలితం పక్కన నమోదు చేయండి. ఆ నమోదే తదుపరి తిప్పడాన్ని సంఘటనగా కాకుండా దినచర్యగా మారుస్తుంది. ఆడిటర్ అడిగే భాగం కూడా అదే.