Chrome onAuthRequired: শংসাপত্র পাঠানোর আগে isProxy যাচাই করুন

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

Chrome-এর webRequest.onAuthRequired ইভেন্টে কার্যকর পার্থক্যকারী হলো isProxy। শুধু একটি প্রম্পট সরানোর জন্য সেই যাচাই সরিয়ে দেওয়া একটি কলব্যাক অরিজিন চ্যালেঞ্জে প্রক্সির শংসাপত্র সরবরাহ শুরু করতে পারে।

আপনি যে প্রক্সিকে বিশ্বাস করতে চান তার সাথে মিলান

isProxy যাচাই করা কেবল শুরু। এছাড়া প্রত্যাশিত প্রক্সি চ্যালেঞ্জার ও অনুরোধের প্রসঙ্গে হ্যান্ডলিং সীমাবদ্ধ করুন। একাধিক এন্ডপয়েন্ট পরিচালনা করা এক্সটেনশনের উচিত সেই এন্ডপয়েন্টের অ্যাকাউন্ট নির্বাচন করা, প্রতিটি চ্যালেঞ্জের জন্য একটি বিশ্বব্যাপী পাসওয়ার্ড নয়।

প্রক্সি রুট সেট করা আর তার লগইন হ্যান্ডল করা একই অনুমতি বা একই API কল বলে ধরে নেবেন না। Chrome এগুলো আলাদাভাবে নথিভুক্ত করে। ইভেন্ট ডেটা ও প্রমাণীকরণ অনুমতির জন্য বর্তমান webRequest রেফারেন্স ব্যবহার করুন। একটি Manifest V3 লিসেনার নিবন্ধনের উদাহরণ কলব্যাকের ভিতরে সিঙ্ক্রোনাস নিবন্ধন ও অ্যাকাউন্ট নির্বাচন দেখায়।

ম্যানিফেস্ট প্রজন্ম যাচাই করুন

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

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

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