პროქსის პარამეტრები დროის ნიშნულის მოთხოვნებისთვის Java 9+ JarSigner API-ში
გამოიყენეთ Java 9+-ის საჯარო JarSigner კონფიგურაცია პროქსის მომთხოვნის, ჰოსტისა და პორტის შემოწმებით შიდა ბრძანების კლასების ნაცვლად.
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 არის არსებული KeyStore.PrivateKeyEntry. მიუთითეთ პროქსის ანგარიშის მნიშვნელობები აპლიკაციის სერტიფიკატების წყაროდან, შემდეგ გამოიყენეთ ეს ხელმომწერი მის ჩვეულებრივ ZipFile და გამომავალი ნაკადის სამუშაო პროცესში.
მომთხოვნის ტიპის პრედიკატი პროქსისა და დანიშნულების ავთენტიფიკაციას ცალ-ცალკე ინახავს და ხელს უშლის დანიშნულების გამოწვევას პროქსის პაროლის მიღებაში; ჰოსტი და პორტი ზღუდავს შუამავალს.
სისტემური თვისებები და ნაგულისხმევი Authenticator მთელ JVM-ზე მოქმედებს. დააყენეთ მათი სიცოცხლის ხანგრძლივობა გაშვებისას, ნაცვლად იმისა, რომ პარალელური სამუშაოების გარშემო შეცვალოთ.
საჯარო jdk.security.jarsigner API თავს არიდებს sun.security.tools.jarsigner.Main-ს და ძველ tools.jar განლაგებებს. მაგალითი იყენებს HTTP TSA-ს; HTTPS TSA-საც სჭირდება საკუთარი HTTPS მარშრუტი და ჩვეულებრივი შემოწმებისა და ავთენტიფიკაციის პოლიტიკა.