Java პროქსის 407 შეცდომები: შეამოწმეთ Basic ავთენტიფიკაცია CONNECT-ისთვის

Java-ს ავტორიზაციის მონაცემები მხოლოდ შესაბამისი პროქსით შეზღუდეთ და HTTPS CONNECT გვირაბებისთვის JDK-ის ცალკე Basic პოლიტიკა შეამოწმეთ.

განმეორებადი 407 ყოველთვის არ ნიშნავს, რომ Java-მ არასწორი პაროლი გაგზავნა. JDK-ის საცნობარო რეალიზაცია ჩვეულებრივ თიშავს Basic ავთენტიფიკაციას HTTPS CONNECT გვირაბებისთვის. პროქსი, რომელიც მხოლოდ Basic-ს სთავაზობს, შეიძლება უარყოფილი იყოს მანამდე, სანამ ავთენტიფიკაციის უკუგამოძახება მონაცემებს მიაწვდის.

შეზღუდეთ მონაცემების მიმწოდებელი უკუგამოძახების მოქმედების არეალი

Authenticator მიაბით Java HTTP კლიენტს და შეზღუდეთ კონფიგურირებული პროქსით:

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();

ეს ერთი კლიენტის გამართვის კოდია და არა გლობალური ნაგულისხმევი ავთენტიფიკატორი. შეცვალეთ სადოკუმენტაციო მისამართი და გამოიყენეთ ამ სერვისისთვის რეალურად მოწოდებული მონაცემები. მომთხოვნის ტიპისა და საბოლოო წერტილის შემოწმება ხელს უშლის იმავე უკუგამოძახებას, რომ საიტის ავთენტიფიკაციის მოთხოვნას დაუფიქრებლად პროქსის ანგარიშით უპასუხოს.

შეამოწმეთ, ავთენტიფიკაციის რომელი ეტაპი მარცხდება

JDK-ს აქვს გამორთული სქემების ცალკე პარამეტრები ჩვეულებრივი HTTP პროქსირებისა და CONNECT გვირაბებისთვის. შესაბამისი სახელებია jdk.http.auth.proxying.disabledSchemes და jdk.http.auth.tunneling.disabledSchemes.

ეს ხსნის, რატომ შეიძლება HTTP ტრაფიკის ავთენტიფიკაცია წარმატებული იყოს, ხოლო იმავე პროქსით HTTPS გვირაბი ვერ შეიქმნას. შეამოწმეთ გაშვების გარემოს conf/net.properties და დანერგვის პოლიტიკა; ნუ ივარაუდებთ, რომ სხვა კომპიუტერზეც იგივე მოქმედი ნაგულისხმევი მნიშვნელობებია.

გამორთული სქემების სიის გლობალურად დაცლა პროქსის საერთო გამოსწორება არ არის. დაუშიფრავ HTTP პროქსისთან გაგზავნილ Basic მონაცემებს დანიშნულებასთან მოგვიანებით შექმნილი TLS კავშირი არ იცავს. ცვლილების დამტკიცებამდე განიხილეთ პროქსის ტრანსპორტი, ავთენტიფიკაციის მეთოდი და დანერგვის პოლიტიკა.

JDK-ის ჩაშენებული ავთენტიფიკაციის დოკუმენტირებული ქცევა არც პროქსის მიერ გამოცხადებული ყველა სქემის მხარდაჭერის დაპირებაა. ხელით მოწოდებული Authorization ან Proxy-Authorization სათაური ავტომატური ავთენტიფიკატორის ნაკადს ცვლის, ამიტომ შეამოწმეთ მორგებული სათაურები, როცა უკუგამოძახების ქცევა მაგალითისგან განსხვავდება.

დაკავშირებული სტატიები