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 ಗಮ್ಯಸ್ಥಾನ ಹಿಂದಿನ ವಿನಿಮಯವನ್ನು ನಂತರ ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಸೇವೆಗೆ ಸರಿಯಾದ ಸಾಗಣೆ ವಿಧಾನ ಮತ್ತು ದೃಢೀಕರಣ ಆಯ್ಕೆಮಾಡಿ; ಅಪರಿಚಿತ ಸಾರ್ವಜನಿಕ ಪ್ರಾಕ್ಸಿಗೆ ಖಾಸಗಿ ಖಾತೆ ಕಳುಹಿಸಬೇಡಿ.
ವಿವರವಾದ ಲಾಗ್‌ಗಳನ್ನು ಹಂಚುವ ಮೊದಲು ನೋಡಿ. ಸಾಮಾನ್ಯ ಲಾಗಿನ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಸಾಧನ ಮರೆಮಾಡಿದರೂ ಬಳಕೆದಾರ ಹೆಸರು, ಒಳಗಿನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು, ಕುಕೀ ಅಥವಾ ಇತರ ಗುರುತಿಸುವ ಮಾಹಿತಿ ಉಳಿಯಬಹುದು.