Java ಪ್ರಾಕ್ಸಿಯ 407 ದೋಷಗಳು: CONNECTಗಾಗಿ Basic ದೃಢೀಕರಣ ಪರಿಶೀಲಿಸಿ

Java ಪ್ರವೇಶ ಮಾಹಿತಿಯನ್ನು ನಿರ್ದಿಷ್ಟ ಪ್ರಾಕ್ಸಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು HTTPS CONNECT ಸುರಂಗಗಳಿಗೆ JDKಯ ಪ್ರತ್ಯೇಕ Basic ದೃಢೀಕರಣ ನೀತಿ ಪರಿಶೀಲಿಸಿ.

ಮತ್ತೆ ಮತ್ತೆ 407 ಬಂದರೆ Java ತಪ್ಪು ಪಾಸ್‌ವರ್ಡ್ ಕಳುಹಿಸಿದೆ ಎಂದೇ ಯಾವಾಗಲೂ ಅರ್ಥವಲ್ಲ. JDKಯ ಉಲ್ಲೇಖ ಅನುಷ್ಠಾನವು ಸಾಮಾನ್ಯವಾಗಿ HTTPS CONNECT ಸುರಂಗಗಳಿಗೆ Basic ದೃಢೀಕರಣವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ. Basic ಮಾತ್ರ ಒದಗಿಸುವ ಪ್ರಾಕ್ಸಿಯು ನಿಮ್ಮ ದೃಢೀಕರಣ callback ಪ್ರವೇಶ ಮಾಹಿತಿಯನ್ನು ನೀಡುವ ಮೊದಲೇ ತಿರಸ್ಕೃತವಾಗಬಹುದು.

ಪ್ರವೇಶ ಮಾಹಿತಿಯ callbackನ ವ್ಯಾಪ್ತಿಯನ್ನು ಸೀಮಿತಗೊಳಿಸಿ

Java HTTP ಕ್ಲೈಂಟ್‌ಗೆ Authenticator ಜೋಡಿಸಿ, ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿರುವ ಪ್ರಾಕ್ಸಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ:

String proxyHost = "203.0.113.10";
int proxyPort = 8080;
String password = System.getenv("PROXY_PASSWORD");
if (password == null) {
    throw new IllegalStateException("Set PROXY_PASSWORD");
}

java.net.Authenticator auth = new java.net.Authenticator() {
    @Override
    protected java.net.PasswordAuthentication getPasswordAuthentication() {
        if (getRequestorType() == RequestorType.PROXY
                && proxyHost.equals(getRequestingHost())
                && proxyPort == getRequestingPort()) {
            return new java.net.PasswordAuthentication(
                "proxy-user", password.toCharArray());
        }
        return null;
    }
};

java.net.http.HttpClient client = java.net.http.HttpClient.newBuilder()
    .proxy(java.net.ProxySelector.of(
        new java.net.InetSocketAddress(proxyHost, proxyPort)))
    .authenticator(auth)
    .connectTimeout(java.time.Duration.ofSeconds(5))
    .build();

ಇದು ಒಂದು ಕ್ಲೈಂಟ್‌ನ ಸೆಟಪ್ ಕೋಡ್, ಜಾಗತಿಕ ಡೀಫಾಲ್ಟ್ ದೃಢೀಕಾರಕವಲ್ಲ. ದಸ್ತಾವೇಜಿನ ವಿಳಾಸ ಬದಲಿಸಿ, ಆ ಸೇವೆಗೆ ನಿಜವಾಗಿ ಒದಗಿಸಿದ ಪ್ರವೇಶ ಮಾಹಿತಿ ಬಳಸಿ. ವಿನಂತಿದಾರರ ಪ್ರಕಾರ ಮತ್ತು ಅಂತ್ಯಬಿಂದುವಿನ ಪರಿಶೀಲನೆಗಳು, ಅದೇ callback ವೆಬ್‌ಸೈಟ್‌ನ ದೃಢೀಕರಣ ಸವಾಲಿಗೆ ಅಜಾಗರೂಕತೆಯಿಂದ ಪ್ರಾಕ್ಸಿ ಖಾತೆಯನ್ನು ನೀಡದಂತೆ ತಡೆಯುತ್ತವೆ.

ದೃಢೀಕರಣದ ಯಾವ ಹಂತ ವಿಫಲವಾಗುತ್ತಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಸಾಮಾನ್ಯ HTTP ಪ್ರಾಕ್ಸಿ ಬಳಕೆ ಮತ್ತು CONNECT ಸುರಂಗಗಳಿಗೆ JDKಯಲ್ಲಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ದೃಢೀಕರಣ ವಿಧಾನಗಳ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ. ಸಂಬಂಧಿತ ಹೆಸರುಗಳು jdk.http.auth.proxying.disabledSchemes ಮತ್ತು jdk.http.auth.tunneling.disabledSchemes.

ಆದ್ದರಿಂದ HTTP ಟ್ರಾಫಿಕ್ ದೃಢೀಕರಣ ಯಶಸ್ವಿಯಾದರೂ ಅದೇ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ HTTPS ಸುರಂಗ ವಿಫಲವಾಗಬಹುದು. ಬೇರೆ ಯಂತ್ರದಲ್ಲೂ ಅದೇ ಪರಿಣಾಮಕಾರಿ ಡೀಫಾಲ್ಟ್‌ಗಳಿವೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ರನ್‌ಟೈಮ್‌ನ conf/net.properties ಮತ್ತು ನಿಯೋಜನೆ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.

ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ವಿಧಾನಗಳ ಪಟ್ಟಿಯನ್ನು ಜಾಗತಿಕವಾಗಿ ಖಾಲಿ ಮಾಡುವುದು ಸಾಮಾನ್ಯ ಪ್ರಾಕ್ಸಿ ಪರಿಹಾರವಲ್ಲ. ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡದ HTTP ಪ್ರಾಕ್ಸಿಗೆ ಕಳುಹಿಸಿದ Basic ಪ್ರವೇಶ ಮಾಹಿತಿಯನ್ನು ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ನಂತರ ನಿರ್ಮಾಣವಾಗುವ TLS ಸಂಪರ್ಕ ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಬದಲಾವಣೆ ಅನುಮೋದಿಸುವ ಮೊದಲು ಪ್ರಾಕ್ಸಿಯ ಸಾರಿಗೆ, ದೃಢೀಕರಣ ವಿಧಾನ ಮತ್ತು ನಿಯೋಜನೆ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.

JDKಯ ಅಂತರ್ನಿರ್ಮಿತ ದೃಢೀಕರಣದ ದಾಖಲಿತ ವರ್ತನೆಯೂ ಪ್ರಾಕ್ಸಿ ಘೋಷಿಸುವ ಪ್ರತಿಯೊಂದು ವಿಧಾನಕ್ಕೆ ಬೆಂಬಲದ ಭರವಸೆಯಲ್ಲ. ಕೈಯಾರೆ ನೀಡಿದ Authorization ಅಥವಾ Proxy-Authorization ಹೆಡರ್ ಸ್ವಯಂಚಾಲಿತ ದೃಢೀಕಾರಕದ ಹರಿವನ್ನು ಬದಲಿಸುತ್ತದೆ; ಆದ್ದರಿಂದ callback ಉದಾಹರಣೆಗಿಂತ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸಿದಾಗ ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು