HTTP 407 ਜਾਂ 401: ਕਿਹੜਾ ਲੌਗਇਨ ਅਸਫਲ ਹੋ ਰਿਹਾ ਹੈ?
ਪ੍ਰਾਕਸੀ ਅਤੇ ਵੈੱਬਸਾਈਟ ਦੀ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਕਿਰਿਆ ਵੱਖ ਕਰੋ, ਸਹੀ ਹੈਡਰ ਵੇਖੋ ਅਤੇ ਲੌਗਇਨ ਜਾਣਕਾਰੀ ਗ਼ਲਤ ਪਾਸੇ ਨਾ ਭੇਜੋ।
407 ਪ੍ਰਾਕਸੀ ਉੱਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਮੰਗਦਾ ਹੈ। 401 ਟੀਚੇ ਦੇ ਸਰੋਤ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਮੰਗਦਾ ਹੈ। ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਦੋਵੇਂ ਮਿਲ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਪਾਸਵਰਡ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣੋ ਕਿ ਕੌਣ ਮੰਗ ਰਿਹਾ ਹੈ।
ਸਟੇਟਸ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਚੁਣੌਤੀ ਦੇ ਹੈਡਰ ਮਿਲਾਓ
| ਜਵਾਬ | ਚੁਣੌਤੀ ਦਾ ਹੈਡਰ | ਲੌਗਇਨ ਜਾਣਕਾਰੀ ਦਾ ਹੈਡਰ | ਸੰਬੰਧਿਤ ਪੱਖ |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | ਵਿਚਕਾਰਲੀ ਪ੍ਰਾਕਸੀ |
| 401 Unauthorized | WWW-Authenticate | Authorization | ਮੂਲ ਸਰੋਤ ਦਾ ਪ੍ਰਮਾਣੀਕਰਨ ਪ੍ਰਵਾਹ |
ਸਟੇਟਸ ਪਹਿਲਾ ਅਹਿਮ ਸੁਰਾਗ ਹੈ, ਪਰ ਪੂਰਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਵੇਖੋ। ਪੰਨੇ ਦੇ ਪਾਠ ਵਿੱਚ 407 ਲਿਖਿਆ ਹੋਣਾ ਅਸਲ HTTP 407 ਜਵਾਬ ਨਹੀਂ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ ਆਪਣਾ ਲੌਗਇਨ ਪੰਨਾ 200 ਵਾਪਸ ਕਰ ਕੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਉੱਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਮੰਗ ਸਕਦਾ ਹੈ।
HTTPS ਵੈੱਬਸਾਈਟ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ 407 ਨਾਲ ਕਿਉਂ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ?
ਆਮ HTTP ਪ੍ਰਾਕਸੀ ਰਾਹੀਂ HTTPS ਬੇਨਤੀ ਜਾਂਦੀ ਹੋਵੇ ਤਾਂ ਕਲਾਇੰਟ ਆਮ ਤੌਰ ’ਤੇ ਪਹਿਲਾਂ CONNECT ਸੁਰੰਗ ਮੰਗਦਾ ਹੈ। ਪ੍ਰਾਕਸੀ ਉਸ CONNECT ਬੇਨਤੀ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਮੰਗ ਸਕਦੀ ਹੈ। ਜੇ ਇਹ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ, ਸੁਰੰਗ ਰਾਹੀਂ ਮੰਜ਼ਿਲ ਦਾ TLS ਸੈਸ਼ਨ ਹਾਲੇ ਬਣਿਆ ਹੀ ਨਹੀਂ। ਵੈੱਬਸਾਈਟ ਦਾ API ਟੋਕਨ ਬਦਲਣ ਨਾਲ ਇਹ ਪੜਾਅ ਠੀਕ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੈ।
ਵਿਸਥਾਰ ਵਾਲੀ ਆਉਟਪੁੱਟ ਨਾਲ ਵੇਖੋ ਚੁਣੌਤੀ ਕਿੱਥੇ ਆਉਂਦੀ ਹੈ:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/ਸਥਾਨਕ ਲਿਸਨਰ ਦੀ ਥਾਂ ਆਪਣਾ ਦੇ ਕੇ ਲਾਗ ਦੀ ਪਹਿਲੀ ਚੁਣੌਤੀ ਪੜ੍ਹੋ। CONNECT ਦੌਰਾਨ 407 ਮੰਜ਼ਿਲ ਦੇ TLS ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ; ਸਫਲ ਸੁਰੰਗ ਤੋਂ ਬਾਅਦ 401 ਮਿਲ ਸਕਦਾ ਹੈ।
ਪ੍ਰਾਕਸੀ ਦੀ ਜਾਣਕਾਰੀ ਉਸ ਦੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਦਿਓ
ਭਰੋਸੇਯੋਗ ਪ੍ਰਬੰਧਕ ਦੇ ਦਿੱਤੇ ਐਂਡਪੋਇੰਟ ਤੇ ਖਾਤੇ ਲਈ curl ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਢੰਗ ਤੈਅ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਨਾ ਦਿੱਤਾ ਪਾਸਵਰਡ ਪੁੱਛ ਸਕਦਾ ਹੈ:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/ਮਿਸਾਲ ਦੇ ਐਂਡਪੋਇੰਟ ਤੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਅਧਿਕਾਰਤ ਸੇਵਾ ਦੀ ਜਾਣਕਾਰੀ ਨਾਲ ਬਦਲੋ। ਕੇਵਲ ਵਰਤੋਂਕਾਰ ਦੇਣ ਨਾਲ ਉੱਪਰਲੀ ਕਮਾਂਡ ਵਿੱਚ ਸਿੱਧਾ ਪਾਸਵਰਡ ਨਹੀਂ ਰੱਖਣਾ ਪੈਂਦਾ। ਸਮਰਥਿਤ ਢੰਗ curl ਬਿਲਡ ਅਤੇ ਪ੍ਰਾਕਸੀ ਮੁਤਾਬਕ ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ; ਗੱਲਬਾਤ ਅਸਫਲ ਹੋਵੇ ਤਾਂ ਅਸਲ ਚੁਣੌਤੀ ਅਤੇ ਬਿਲਡ ਦੀ ਸਮਰੱਥਾ ਵੇਖੋ।
ਪ੍ਰਾਕਸੀ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਵਿਕਲਪ curl ਦੇ ਮੂਲ ਸਰਵਰ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣੀਕਰਨ ਤੋਂ ਵੱਖ ਹੈ। ਪ੍ਰਾਕਸੀ ਚੁਣੌਤੀ ਦੇ ਜਵਾਬ ਦੀ ਥਾਂ ਮੂਲ ਸਰਵਰ ਦਾ Authorization ਹੈਡਰ ਨਾ ਜੋੜੋ। ਪ੍ਰਾਕਸੀ ਲੌਗਇਨ ਹੈਡਰ ਨੂੰ ਹੱਥੀਂ ਬੇਸੰਬੰਧ ਬੇਨਤੀਆਂ ਵਿੱਚ ਨਾ ਭੇਜੋ ਜਾਂ ਸਾਰੀ ਐਪ ਵਿੱਚ ਮੁੜ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਹੈਡਰਾਂ ਵਿੱਚ ਨਾ ਰੱਖੋ।
ਜੇ ਪ੍ਰਾਕਸੀ ਲਗਾਤਾਰ 407 ਵਾਪਸ ਕਰੇ
- ਚਾਹੀਦੀ ਪ੍ਰਾਕਸੀ ਦੇ ਹੋਸਟ ਤੇ ਪੋਰਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
- Basic ਮੰਨਣ ਦੀ ਥਾਂ ਪ੍ਰਾਕਸੀ ਦੇ ਦੱਸੇ ਢੰਗ ਵੇਖੋ।
- ਖਾਤੇ ਦੀ ਹਾਲਤ ਅਤੇ ਸੇਵਾ ਦੇ ਮੰਗੇ ਵਰਤੋਂਕਾਰ ਨਾਂ ਦੇ ਰੂਪ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
- ਲੌਗਇਨ ਜਾਣਕਾਰੀ URL ਵਿੱਚ ਹੋਵੇ ਤਾਂ ਖਾਸ ਅੱਖਰ ਕਿਵੇਂ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਵੇਖੋ।
- ਪਤਾ ਕਰੋ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਨਾਲ ਜੁੜਿਆ ਕਾਰਪੋਰੇਟ ਪ੍ਰਮਾਣੀਕਰਨ ਰਨਟਾਈਮ ਜਾਂ ਪਲੇਟਫਾਰਮ ਦੀ ਮਦਦ ਮੰਗਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
- ਕਲਾਇੰਟ ਦੇ ਸਬੂਤ ਕਾਫ਼ੀ ਨਾ ਹੋਣ ਤਾਂ ਪ੍ਰਬੰਧਕ ਤੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਹਟਾਇਆ ਬੇਨਤੀ ਪਛਾਣਕਰਤਾ ਜਾਂ ਸਰਵਰ ਲਾਗ ਐਂਟਰੀ ਮੰਗੋ।
ਸਫਲ ਲੌਗਇਨ ਤੋਂ ਬਾਅਦ ਵੀ 403 ਜਾਂ ਨਾਮਨਜ਼ੂਰ CONNECT ਪਹੁੰਚ ਨੀਤੀ ਦਾ ਫ਼ੈਸਲਾ ਹੋ ਸਕਦਾ ਹੈ। ਹੋਰ ਪਾਸਵਰਡ ਅਜ਼ਮਾਉਣ ਨਾਲ ਮਨਾਹੀ ਵਾਲੀ ਮੰਜ਼ਿਲ ਦਾ ਹੱਕ ਨਹੀਂ ਮਿਲੇਗਾ।
ਮੰਜ਼ਿਲ ਦਾ HTTPS ਹਰ ਪ੍ਰਾਕਸੀ ਲੌਗਇਨ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨਹੀਂ ਬਚਾਉਂਦਾ
ਪ੍ਰਾਕਸੀ ਪ੍ਰਮਾਣੀਕਰਨ ਮੰਜ਼ਿਲ ਦੇ TLS ਤੋਂ ਪਹਿਲਾਂ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਪ੍ਰਾਕਸੀ ਤੱਕ ਕਨੈਕਸ਼ਨ ਇਨਕ੍ਰਿਪਟ ਨਹੀਂ ਅਤੇ ਢੰਗ ਉਸ ਉੱਤੇ ਮੁੜ ਵਰਤਣਯੋਗ ਜਾਣਕਾਰੀ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ HTTPS ਮੰਜ਼ਿਲ ਪਿਛਲੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕਰਦੀ। ਸੇਵਾ ਮੁਤਾਬਕ ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਚੁਣੋ; ਅਣਜਾਣ ਜਨਤਕ ਪ੍ਰਾਕਸੀ ਨੂੰ ਨਿੱਜੀ ਖਾਤੇ ਨਾ ਭੇਜੋ।
ਵਿਸਥਾਰ ਵਾਲੇ ਲਾਗ ਸਾਂਝੇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੋ। ਆਮ ਲੌਗਇਨ ਖੇਤਰ ਲੁਕਾਉਣ ’ਤੇ ਵੀ ਵਰਤੋਂਕਾਰ ਨਾਂ, ਅੰਦਰਲੇ ਐਂਡਪੋਇੰਟ ਨਾਂ, ਕੁਕੀ ਜਾਂ ਹੋਰ ਪਛਾਣਯੋਗ ਡਾਟਾ ਰਹਿ ਸਕਦਾ ਹੈ।