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 ഉദാഹരണത്തിൽനിന്ന് വ്യത്യസ്തമായി പ്രവർത്തിക്കുമ്പോൾ ഇഷ്ടാനുസൃത ഹെഡറുകൾ പരിശോധിക്കുക.