OpenVPN ਦੀ auth-user-pass-verify ਸਕ੍ਰਿਪਟ: ਐਗਜ਼ਿਟ ਕੋਡ ਠੀਕ ਕਰੋ

OpenVPN ਲੌਗਇਨ ਸਕ੍ਰਿਪਟ ਦੇ ਠੀਕ ਇੱਕ ਆਉਟਪੁੱਟ ’ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ: ਐਗਜ਼ਿਟ ਸਥਿਤੀ ’ਤੇ। ਸਕ੍ਰਿਪਟ ਬਾਕੀ ਜੋ ਕੁਝ ਕਰਦੀ ਹੈ ਉਹ ਸਜਾਵਟ ਹੈ। ਹੁੱਕ ਸਹੀ ਤਸਦੀਕਕਰਤਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਜਵਾਬ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਦੋਸਤਾਨਾ ਲਾਈਨ ਛਾਪ ਸਕਦਾ ਹੈ, ਪਰ ਲੇਖਕ ਦੇ ਇਰਾਦੇ ਦੇ ਉਲਟ ਅਰਥ ਵਾਲੀ ਸਥਿਤੀ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਸਮਝੌਤਾ ਪੜ੍ਹੋ ਅਤੇ ਉਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਅਡਾਪਟਰ ਲਿਖੋ, ਫਿਰ ਬੱਗ ਦਾ ਇਹ ਪੂਰਾ ਵਰਗ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸਮਝੌਤਾ ਛੋਟਾ ਹੈ: ਜਮ੍ਹਾ ਕੀਤਾ ਖਾਤਾ ਪਛਾਣੋ, ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਤਸਦੀਕਕਰਤਾ ਨੂੰ ਲੋੜੀਂਦਾ ਸਵਾਲ ਪੁੱਛੋ ਅਤੇ ਉਸ ਬੇਨਤੀ ਲਈ ਸਿਰਫ਼ ਉਸੇ ਤਸਦੀਕਕਰਤਾ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਸਕਾਰਾਤਮਕ ਨਤੀਜਾ ਸਵੀਕਾਰ ਕਰੋ। ਬਾਕੀ ਸਭ ਢਾਂਚਾ ਹੈ।

ਉਹ ਤਿੰਨ ਸਥਿਤੀਆਂ ਜੋ ਹੁੱਕ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ

auth-user-pass-verify ਲਈ OpenVPN 2.6 ਮੈਨੂਅਲ ਐਗਜ਼ਿਟ ਕੋਡ 0 ਨੂੰ ਸਵੀਕ੍ਰਿਤੀ, 1 ਨੂੰ ਰੱਦ ਅਤੇ 2 ਨੂੰ ਮੁਲਤਵੀ ਪ੍ਰਮਾਣਿਕਤਾ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਸਰਵਰ ਸਿਰਫ਼ ਇਹੀ ਤਿੰਨ ਜਵਾਬ ਸਮਝਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਕਨੈਕਸ਼ਨ ’ਤੇ ਵੱਖਰਾ ਅਸਰ ਹੁੰਦਾ ਹੈ। ਜੋ ਸਕ੍ਰਿਪਟ ਆਪਣੇ ਆਖ਼ਰੀ ਹੁਕਮ ਦੀ ਸਥਿਤੀ ਨਾਲ ਬਾਹਰ ਨਿਕਲਦੀ ਹੈ, ਉਸ ਨੇ ਅਸਲ ਵਿੱਚ ਲੌਗ ਕਾਲ ਜਾਂ ਸਫ਼ਾਈ ਦੇ ਕਦਮ ਨੂੰ ਵੋਟ ਪਾਉਣ ਦਿੱਤੀ ਹੈ। ਹਰ ਸ਼ਾਖਾ ਵਿੱਚ ਸਥਿਤੀ ਸਪਸ਼ਟ ਲਿਖੋ, ਉਨ੍ਹਾਂ ਸ਼ਾਖਾਵਾਂ ਸਮੇਤ ਜੋ ਕਦੇ ਤਸਦੀਕਕਰਤਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੀਆਂ।

HTTP ਸਫਲਤਾ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲਤਾ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਇਸ ਹੁੱਕ ਦੇ ਗ਼ਲਤ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ। 202 ਜਵਾਬ ਦਾ ਅਰਥ ਹੈ ਕਿ ਬੇਨਤੀ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਸਵੀਕਾਰ ਹੋਈ, ਇਹ ਨਹੀਂ ਕਿ ਪਾਸਵਰਡ ਤਸਦੀਕ ਹੋਇਆ। ਲੋੜੀਂਦੀ ਸਥਿਤੀ, ਜਵਾਬ ਦਾ ਰੂਪ ਅਤੇ ਅੰਤਿਮ ਫ਼ੈਸਲਾ ਤੁਹਾਨੂੰ ਦਿੱਤੇ API ਸਮਝੌਤੇ ਤੋਂ ਤੈਅ ਕਰੋ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਲੱਗਣ ਕਾਰਨ ਕੋਈ ਫ਼ੀਲਡ ਨਾਮ ਨਾ ਘੜੋ।

ਜੇ ਜਵਾਬ ਸੱਚਮੁੱਚ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਮੁਲਤਵੀ ਰਾਹ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੋ ਮੁਲਤਵੀ ਕੋਸ਼ਿਸ਼ ਕਦੇ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ, ਉਹ ਸਮਾਂ-ਸੀਮਾ ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਸਰੋਤ ਰੋਕੀ ਰੱਖਦੀ ਹੈ।

ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਫ਼ਾਈਲ ਨੂੰ ਠੀਕ ਉਸੇ ਤਰ੍ਹਾਂ ਪੜ੍ਹੋ ਜਿਵੇਂ ਉਹ ਲਿਖੀ ਹੈ

ਦਸਤਾਵੇਜ਼ੀ ਫ਼ਾਈਲ-ਰਾਹੀਂ ਢੰਗ ਵਿੱਚ, ਸਰਵਰ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਨੂੰ ਅਸਥਾਈ ਫ਼ਾਈਲ ਦੀਆਂ ਪਹਿਲੀਆਂ ਦੋ ਲਾਈਨਾਂ ਵਜੋਂ ਲਿਖਦਾ ਹੈ, ਉਹ ਪਾਥ ਸਕ੍ਰਿਪਟ ਨੂੰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰਿਪਟ ਦੇ ਵਾਪਸ ਆਉਣ ’ਤੇ ਫ਼ਾਈਲ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਉਹ ਦੋ ਲਾਈਨਾਂ ਡੇਟਾ ਵਜੋਂ ਪੜ੍ਹੋ: ਫ਼ਾਈਲ ਨੂੰ ਕਦੇ source ਨਾ ਕਰੋ, ਉਸ ਦਾ ਮੁਲਾਂਕਣ ਕਦੇ ਨਾ ਕਰੋ, ਅਤੇ ਉਸ ਦੀ ਸਮੱਗਰੀ ਕਦੇ ਐਸੀ ਕਮਾਂਡ ਲਾਈਨ ਵਿੱਚ ਨਾ ਲਾਓ ਜਿੱਥੇ ਪ੍ਰੋਸੈਸ ਟੇਬਲ ਉਸ ਨੂੰ ਵੇਖ ਸਕੇ। ਪਾਸਵਰਡ ਨੂੰ ਬਾਈਟ-ਦਰ-ਬਾਈਟ ਸੰਭਾਲੋ, ਕਿਉਂਕਿ ਵਰਤੋਂਕਾਰ ਨਾਮ ਵਾਂਗ ਉਸ ਨੂੰ ਸਧਾਰਨ ਬਣਾਉਣਾ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਚੁੱਪ-ਚਾਪ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਉਸ ਅਸਥਾਈ ਫ਼ਾਈਲ ਦੀ ਡਾਇਰੈਕਟਰੀ ਤੈਨਾਤੀ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਪੱਕਾ ਕਰੋ ਕਿ ਉਹ ਮੌਜੂਦ ਹੈ ਅਤੇ ਹੋਸਟ ਉੱਤੇ ਸਾਰਿਆਂ ਲਈ ਪੜ੍ਹਨਯੋਗ ਨਹੀਂ ਹੈ।

ਤਸਦੀਕਕਰਤਾ ਦਾ ਆਪਣਾ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਵਰਤੋਂਕਾਰ ਵਾਲੇ ਤੋਂ ਵੱਖ ਰੱਖੋ: ਉਹ ਗੇਟਵੇ ਏਕੀਕਰਣ ਦਾ ਹਿੱਸਾ ਹੈ, ਪਲੇਟਫ਼ਾਰਮ ਦੇ ਸੀਕ੍ਰੇਟ ਸਟੋਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਤਸਦੀਕ ਦੀ ਇਜਾਜ਼ਤ ਲੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਕੋਈ ਖ਼ਾਸ ਵਿਅਕਤੀ ਪ੍ਰਮਾਣਿਤ ਹੋਇਆ। ਹੁੱਕ ਨੂੰ ਦੂਜਾ ਪਾਸਵਰਡ ਤਸਦੀਕਕਰਤਾ ਬਣਨ ਵੀ ਨਾ ਦਿਓ। ਹੈਸ਼ ਤੁਲਨਾ ਹੱਥੋਂ ਮੁੜ ਲਿਖਣਾ ਲੂਪ ਨੂੰ ਅਨੁਕੂਲ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਤਸਦੀਕਕਰਤਾ ਖਾਤਾ ਸਟੋਰ ਦੀ ਲੂਣ ਵਾਲੀ ਅਤੇ ਮਹਿੰਗੀ ਸਕੀਮ ਪਹਿਲਾਂ ਹੀ ਸਮਝਦਾ ਹੈ।

ਉਸ ਜਵਾਬ ਦਾ ਅਰਥ ਤੈਅ ਕਰੋ ਜਿਸ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ

ਸਮਾਂ-ਸੀਮਾਵਾਂ, ਟ੍ਰਾਂਸਪੋਰਟ ਗ਼ਲਤੀਆਂ, ਵਿਗੜੇ ਜਵਾਬ ਅਤੇ ਉਪਲਬਧ ਨਾ ਹੋਣ ਵਾਲਾ ਬੈਕਐਂਡ ਇੱਕ ਗੁਣ ਸਾਂਝਾ ਕਰਦੇ ਹਨ: ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਕਾਰਾਤਮਕ ਤਸਦੀਕ ਨਹੀਂ ਹੈ। ਹੁੱਕ ਨੂੰ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਲਈ ਬੰਦ ਹੋ ਕੇ ਨਾਕਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਅਜਿਹਾ ਕਾਰਨ ਦਰਜ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ’ਤੇ ਆਪਰੇਟਰ ਕਾਰਵਾਈ ਕਰ ਸਕੇ। ਉਹ ਕਾਰਨ ਸੁਰੱਖਿਅਤ ਲੌਗ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਵਿਅਕਤੀ ਨੂੰ ਵਾਪਸ ਦਿੱਤੇ ਸੁਨੇਹੇ ਵਿੱਚ ਨਹੀਂ।

ਉਨ੍ਹਾਂ ਰਾਹਾਂ ਪ੍ਰਤੀ ਵੀ ਉੱਨੀ ਹੀ ਸਾਵਧਾਨੀ ਰੱਖੋ ਜੋ ਤਸਦੀਕਕਰਤਾ ਤੱਕ ਬਿਲਕੁਲ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਗ਼ਾਇਬ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਮੁੱਲ, ਨਾ ਪੜ੍ਹੀ ਜਾ ਸਕਣ ਵਾਲਾ ਸੀਕ੍ਰੇਟ ਜਾਂ ਨਾ ਲੱਗੀ ਨਿਰਭਰਤਾ ਨੂੰ ਅਚਾਨਕ ਸਵੀਕ੍ਰਿਤੀ ਦੀ ਥਾਂ ਵੱਖਰੇ ਓਪਰੇਸ਼ਨਲ ਚਿੰਨ੍ਹ ਨਾਲ ਰੱਦ ਪੈਦਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ ਸ਼ਾਖਾਵਾਂ ਲੈਬ ਵਿੱਚ ਨਿਰਭਰਤਾ ਹਟਾ ਕੇ ਪਰਖੋ, ਉਨ੍ਹਾਂ ਬਾਰੇ ਸੋਚਣ ਦੀ ਥਾਂ। ਜਿੱਥੇ ਲੌਗ ਕਰਨ ਦੀ ਨਾਕਾਮੀ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਬਦਲ ਸਕਦੀ ਹੈ, ਉੱਥੇ ਲੌਗਿੰਗ ਫ਼ੈਸਲੇ ਦਾ ਹਿੱਸਾ ਬਣ ਗਈ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਬਿਨਾਂ ਨੁਕਸਾਨ ਦਾ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਰਵਰ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਇੱਥੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ: ਵਰਤੋਂਕਾਰ-ਪਰਿਭਾਸ਼ਿਤ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਸਨਮਾਨ ਸਿਰਫ਼ ਤਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਚੱਲ ਰਹੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਉਨ੍ਹਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਸੁਰੱਖਿਆ ਪੱਧਰ ’ਤੇ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਹ ਸੈਟਿੰਗ ਵਧਾਉਣ ਵਾਲੀ ਡਿਫ਼ਾਲਟ ਨਹੀਂ ਬਲਕਿ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੀ ਗਈ ਹੈ।

ਫ਼ੈਸਲਾ ਤਸਦੀਕ ਕਰੋ, ਛਾਪੀ ਲਾਈਨ ਨਹੀਂ

ਅਜਿਹੀ ਪਰਖ ਬਣਾਓ ਜੋ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਨੂੰ ਸਿੱਧਾ ਜਾਂਚਦੀ ਹੈ। ਨਮੂਨਾ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਫ਼ਾਈਲ ਲਿਖੋ, ਜਾਣੇ-ਪਛਾਣੇ ਚੰਗੇ ਅਤੇ ਜਾਣੇ-ਪਛਾਣੇ ਖਰਾਬ ਖਾਤੇ ਨਾਲ ਉਸ ਵਿਰੁੱਧ ਹੁੱਕ ਚਲਾਓ, ਅਤੇ ਸਕ੍ਰਿਪਟ ਜੋ ਟੈਕਸਟ ਛਾਪਦੀ ਹੈ ਉਸ ਦੀ ਥਾਂ ਸ਼ੈੱਲ ਜੋ ਸਥਿਤੀ ਦੱਸਦਾ ਹੈ ਉਹ ਪੜ੍ਹੋ। ਉਹ ਇੱਕੋ ਜਾਂਚ ਕਲਾਇੰਟ ਦੇ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤੀਆਂ ਸਮਝੌਤਾ-ਬੱਗ ਫੜ ਲੈਂਦੀ ਹੈ।

ਫਿਰ ਉਹੀ ਕੇਸ ਅਸਲ ਕਲਾਇੰਟ ਰਾਹੀਂ ਗ਼ੈਰ-ਉਤਪਾਦਨ ਸਰੋਤੇ ਦੇ ਸਾਹਮਣੇ ਚਲਾਓ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਸਰਵਰ ਨੇ ਕੀ ਦਰਜ ਕੀਤਾ: ਸਵੀਕਾਰ, ਰੱਦ ਜਾਂ ਮੁਲਤਵੀ। ਨਿਸ਼ਕਿਰਿਆ ਖਾਤਾ, ਗ਼ਲਤ ਪਾਸਵਰਡ, ਵਿਗੜਿਆ ਤਸਦੀਕਕਰਤਾ ਜਵਾਬ, ਸਮਾਂ-ਸੀਮਾ ਅਤੇ ਨਾ ਪਹੁੰਚਣਯੋਗ ਤਸਦੀਕਕਰਤਾ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਕੋਈ ਕੇਸ ਐਸੀ ਹਾਲਤ ਵਿੱਚ ਪੁੱਜੇ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਾਮ ਨਹੀਂ ਦੇ ਸਕਦੇ, ਤਾਂ ਅਡਾਪਟਰ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ।

ਤਸਦੀਕਕਰਤਾ ਨਤੀਜੇ ਤੋਂ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਤੱਕ ਦਾ ਮੈਪਿੰਗ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਦੇ ਕੋਲ ਰੱਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਕੋਡ ਦੀ ਉਲਟੀ ਇੰਜੀਨੀਅਰਿੰਗ ਕੀਤੇ ਬਿਨਾਂ ਸਮਝੌਤਾ ਪੜ੍ਹ ਸਕੇ।