ਤੈਅ ਕੀਤਾ ਕੰਮ ਜਾਂ ਮਨੁੱਖੀ ਲੌਗਇਨ: 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

ਪ੍ਰਿੰਸੀਪਲ, ਦਾਇਰਾ, ਘੁਮਾਉਣ ਦਾ ਮਾਲਕ ਅਤੇ ਲਾਗੂਕਰਨ ਵਾਤਾਵਰਣ ਉਸ ਨਤੀਜੇ ਦੇ ਕੋਲ ਦਰਜ ਕਰੋ। ਉਹੀ ਰਿਕਾਰਡ ਅਗਲੇ ਘੁਮਾਉਣ ਨੂੰ ਘਟਨਾ ਨਹੀਂ ਸਗੋਂ ਰੁਟੀਨ ਬਣਾਉਂਦਾ ਹੈ। ਆਡੀਟਰ ਜੋ ਮੰਗਦਾ ਹੈ ਉਹ ਵੀ ਉਹੀ ਹਿੱਸਾ ਹੈ।