OkHttp বেসিক প্রক্সি প্রমাণীকরণ: প্রত্যাখ্যাত পুনঃচেষ্টা বন্ধ করুন

বেসিক প্রমাণীকরণ প্রদানকারী HTTP প্রক্সির জন্য, OkHttp-এর proxyAuthenticator শংসাপত্র বহনকারী একটি অনুরোধ ফেরত দিতে পারে। অনুমোদন প্রচেষ্টা ইতিমধ্যে প্রত্যাখ্যাত হওয়ার পরে একই উত্তর আবার না পাঠিয়ে null ফেরত দিন:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

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

যদি চূড়ান্ত ফলাফল 407 থাকে, তবে নির্বাচিত প্রক্সি, ঘোষিত স্কিম এবং নথিভুক্ত অ্যাকাউন্ট পরিচয় তুলনা করুন। প্রত্যাখ্যাত পাসওয়ার্ড, অসমর্থিত পদ্ধতি এবং ভুল ব্যবহারকারীনামের রূপের জন্য ভিন্ন সংশোধন প্রয়োজন। সেই পর্যবেক্ষণ এবং চূড়ান্ত অবস্থা রিড্যাক্ট করা ডায়াগনস্টিকে রাখুন।

CONNECT-এর আরেকটি কলব্যাক প্রসঙ্গ আছে: OkHttp টানেল খোলার আগে একটি কৃত্রিম প্রি-এম্পটিভ প্রক্সি-প্রমাণীকরণ চ্যালেঞ্জ নথিভুক্ত করে। প্রতিটি কলব্যাক সাধারণ গন্তব্য উত্তর বলে ধরে না নিয়ে API অনুযায়ী সেই প্রসঙ্গ পরিচালনা করুন।

পৃথক authenticator গন্তব্য-সার্ভার প্রমাণীকরণের জন্য। এর শংসাপত্র প্রক্সি লগইন থেকে আলাদা রাখুন; প্রতিটি বহির্গামী অনুরোধে প্রক্সি পাসওয়ার্ড বসানো একটি সাধারণ ইন্টারসেপ্টর এটি ভুল পরিধিতে পাঠাতে পারে।

ঐতিহাসিক প্রতিবেদনগুলি বাস্তবায়নের বাগও বর্ণনা করে, যার মধ্যে প্রত্যাখ্যাত প্রক্সি-উত্তরের বডি পরিচালনা অন্তর্ভুক্ত। বর্তমান ব্যর্থতাকে পুরনো প্রতিবেদনে আরোপ করার আগে OkHttp সংস্করণ এবং চূড়ান্ত বিনিময় লিপিবদ্ধ করুন। পুনঃচেষ্টার সিদ্ধান্তের এখনও এমন অপরিবর্তিত শংসাপত্র প্রচেষ্টা থামানো উচিত যার কোনো উপকারী নতুন উত্তর নেই।