বারবার 407 আসার অর্থ সব সময় Java ভুল পাসওয়ার্ড পাঠিয়েছে এমন নয়। JDK-র রেফারেন্স বাস্তবায়ন সাধারণত HTTPS CONNECT টানেলিংয়ের জন্য Basic প্রমাণীকরণ নিষ্ক্রিয় রাখে। শুধু Basic দেওয়া কোনো প্রক্সি আপনার প্রমাণীকরণ কলব্যাক শংসাপত্র সরবরাহ করার আগেই প্রত্যাখ্যাত হতে পারে।

শংসাপত্রের কলব্যাকের পরিসর সীমিত রাখুন

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

এটি একটি ক্লায়েন্ট সেটআপের কোড, কোনো বৈশ্বিক ডিফল্ট প্রমাণীকরণকারী নয়। নথির জন্য ব্যবহৃত ঠিকানা বদলে সেই পরিষেবার জন্য সত্যিই দেওয়া শংসাপত্র ব্যবহার করুন। অনুরোধকারীর ধরন ও এন্ডপয়েন্ট যাচাই একই কলব্যাককে কোনো ওয়েবসাইটের প্রমাণীকরণ চ্যালেঞ্জে অসতর্কভাবে প্রক্সি অ্যাকাউন্ট দেওয়া থেকে আটকায়।

প্রমাণীকরণের কোন ধাপে ব্যর্থতা হচ্ছে যাচাই করুন

সাধারণ 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 হেডার স্বয়ংক্রিয় প্রমাণীকরণকারীর প্রবাহ বদলে দেয়; তাই কলব্যাকের আচরণ উদাহরণ থেকে আলাদা হলে কাস্টম হেডার পরীক্ষা করুন।

সম্পর্কিত নিবন্ধ