Proksi-agordoj por tempstemplaj petoj per la Java 9+ JarSigner API

Uzu la publikan JarSigner-agordon de Java 9+ kun kontroloj de proksi-petanto, gastiganto kaj pordo anstataŭ internaj komandaj klasoj.

System.setProperty("http.proxyHost", "proxy.example");
System.setProperty("http.proxyPort", "8080");

java.net.Authenticator.setDefault(new java.net.Authenticator() {
    @Override
    protected java.net.PasswordAuthentication getPasswordAuthentication() {
        if (getRequestorType() == RequestorType.PROXY
                && "proxy.example".equalsIgnoreCase(getRequestingHost())
                && getRequestingPort() == 8080) {
            return new java.net.PasswordAuthentication(
                proxyUser, proxyPassword.toCharArray());
        }
        return null;
    }
});

var signer = new jdk.security.jarsigner.JarSigner.Builder(signingEntry)
    .tsa(java.net.URI.create("http://tsa.example/"))
    .build();

signingEntry estas la ekzistanta KeyStore.PrivateKeyEntry. Provizu proksi-kontajn valorojn el la identiga fonto de la aplikaĵo, poste uzu ĉi tiun subskribilon en ĝia kutima laborfluo ZipFile kaj eliga fluo.

La predikato de petanto-tipo tenas proksian kaj celan aŭtentikigon apartaj, malhelpante ke cela defio ricevu la proksian pasvorton; gastiganto kaj pordo limigas la peranton.

Sistemaj propraĵoj kaj la defaŭlta Authenticator efikas al la tuta JVM. Fiksu ilian vivdaŭron ĉe lanĉo anstataŭ ŝalti ilin ĉirkaŭ samtempaj taskoj.

La publika jdk.security.jarsigner API evitas sun.security.tools.jarsigner.Main kaj malnovajn tools.jar aranĝojn. La ekzemplo uzas HTTP TSA; HTTPS TSA ankaŭ bezonas sian HTTPS-vojon kaj la kutiman kontrolan kaj aŭtentikigan politikon.

Rilataj artikoloj