නියමිත කාර්යයක් ද නැතිනම් මිනිස් පිවිසුමක් ද: API ට දැකිය යුත්තේ කුමන අනන්‍යතාවද?

නියමිත කාර්යයක් සහ පිවිසුම් ඉල්ලීමක් ඉදිරියේ සිටින පුද්ගලයෙක් එකම 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

ප්‍රින්සිපල්, විෂය පථය, කරකැවීමේ හිමිකරු සහ ක්‍රියාත්මක කිරීමේ පරිසරය එම ප්‍රතිඵලය අසල සටහන් කරන්න. එම වාර්තාව ඊළඟ කරකැවීම සිද්ධියක් නොව නිතිපතා කටයුත්තක් කරයි. විගණකයෙකු ඉල්ලන කොටස ද එයයි.