Java પ્રોક્સીની 407 ભૂલો: CONNECT માટે 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નું વર્તન ઉદાહરણથી જુદું હોય ત્યારે કસ્ટમ હેડર તપાસો.