திட்டமிட்ட பணியா அல்லது மனித உள்நுழைவா: 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

பிரின்சிபால், வரம்பு, சுழற்றலின் உரிமையாளர் மற்றும் செயலாக்கச் சூழலை அந்த முடிவின் அருகில் பதிவு செய்யுங்கள். அந்தப் பதிவே அடுத்த சுழற்றலை சம்பவமாக அல்ல, வழக்கமான பணியாக மாற்றுகிறது. தணிக்கையாளர் கேட்பதும் அந்தப் பகுதியே.