Erreurs proxy 407 en Java : vérifiez Basic pour CONNECT
Limitez les identifiants proxy Java au proxy et vérifiez la politique Basic distincte du JDK pour les tunnels HTTPS CONNECT.
Un 407 répété ne signifie pas toujours que Java a envoyé un mauvais mot de passe. L’implémentation de référence du JDK désactive normalement l’authentification Basic pour les tunnels HTTPS CONNECT. Un proxy n’offrant que Basic peut être rejeté avant que le callback d’authentification ne fournisse les identifiants.
Limitez la portée du callback d’identifiants
Associez un Authenticator au client HTTP Java et limitez-le au proxy configuré :
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();
Il s’agit de code de configuration d’un client, pas d’un authentificateur global par défaut. Remplacez l’adresse de documentation et utilisez des identifiants réellement fournis pour ce service. Les vérifications du type de demandeur et du point de connexion empêchent le même callback de proposer trop facilement le compte proxy à une demande d’authentification d’un site.
Vérifiez quelle étape d’authentification échoue
Le JDK possède des réglages de schémas désactivés distincts pour le proxy HTTP ordinaire et les tunnels CONNECT. Leurs noms sont jdk.http.auth.proxying.disabledSchemes et jdk.http.auth.tunneling.disabledSchemes.
Cela explique pourquoi le trafic HTTP peut s’authentifier alors qu’un tunnel HTTPS via le même proxy échoue. Vérifiez le conf/net.properties de l’environnement d’exécution et la politique de déploiement plutôt que de supposer les mêmes valeurs effectives par défaut sur une autre machine.
Vider globalement une liste de schémas désactivés n’est pas une réparation générale de proxy. Les identifiants Basic envoyés à un proxy HTTP en clair ne sont pas protégés par la connexion TLS ultérieure à la destination. Examinez le transport du proxy, la méthode d’authentification et la politique de déploiement avant d’approuver un changement.
Le comportement d’authentification intégré documenté du JDK ne promet pas non plus de prendre en charge tous les schémas annoncés par un proxy. Un en-tête Authorization ou Proxy-Authorization fourni manuellement modifie le flux de l’authentificateur automatique ; inspectez vos en-têtes si le callback se comporte autrement que dans l’exemple.