ನಿಗದಿತ ಕೆಲಸ ಅಥವಾ ಮಾನವ ಲಾಗಿನ್: 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

ಪ್ರಿನ್ಸಿಪಾಲ್, ವ್ಯಾಪ್ತಿ, ತಿರುಗುವಿಕೆಯ ಮಾಲೀಕ ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಪರಿಸರವನ್ನು ಆ ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆಯೇ ಮುಂದಿನ ತಿರುಗುವಿಕೆಯನ್ನು ಘಟನೆಯಲ್ಲ, ದಿನಚರಿಯಾಗಿಸುತ್ತದೆ. ಅದು ಆಡಿಟರ್ ಕೇಳುವ ಭಾಗವೂ ಹೌದು.