ब्राउजर एक्सटेन्सनले दुई फरक ठाउँबाट प्रमाणीकरण चुनौतीहरू भेट्न सक्छ: अनुरोध बोक्ने प्रोक्सी र गन्तव्य वेबसाइट। तिनीहरूले स्वचालित रूपमा एउटै खाता पाउनु हुँदैन।

Chrome को webRequest.onAuthRequired घटनामा उपयोगी भेदक isProxy हो। केवल प्रम्प्ट हराउनका लागि त्यो जाँच हटाउने कलब्याकले उत्पत्ति चुनौतीलाई प्रोक्सीको प्रमाण दिन थाल्न सक्छ।

तपाईं विश्वास गर्न चाहनुभएको प्रोक्सीसँग मिलाउनुहोस्

isProxy जाँच गर्नु सुरुवात हो। अपेक्षित प्रोक्सी चुनौतीकर्ता र अनुरोध सन्दर्भमा पनि ह्यान्डलिङ सीमित गर्नुहोस्। धेरै इन्डपोइन्ट व्यवस्थापन गर्ने एक्सटेन्सनले हरेक चुनौतीका लागि एउटै विश्वव्यापी पासवर्ड नभई त्यो इन्डपोइन्टको खाता छान्नुपर्छ।

प्रोक्सी मार्ग सेट गर्नु र यसको लगइन ह्यान्डल गर्नु एउटै अनुमति वा एउटै API कल हो भनी नठान्नुहोस्। Chrome ले तिनीहरूलाई छुट्टाछुट्टै कागजात गर्छ। घटना डेटा र प्रमाणीकरण अनुमतिका लागि हालको webRequest सन्दर्भ प्रयोग गर्नुहोस्। Manifest V3 श्रोता दर्ताको उदाहरण ले कलब्याकभित्रको सिंक्रोनस दर्ता र खाता चयन देखाउँछ।

म्यानिफेस्ट पुस्ता जाँच गर्नुहोस्

प्रयोगात्मक WebRequest API उल्लेख गर्ने उदाहरणहरू पुराना एक्सटेन्सन रिलिजबाट आउँछन्। हालका अनुमति आवश्यकताहरू एक्सटेन्सनको म्यानिफेस्ट पुस्ता र डिप्लोयमेन्ट मोडेलमा निर्भर छन्। विशेष गरी, प्रमाणीकरण ह्यान्डलिङको आफ्नै समर्थित अनुमति मार्ग छ; अप्रचलित ब्लकिङ श्रोता उदाहरणले Manifest V3 एक्सटेन्सनले यसलाई अपरिवर्तित रूपमा चलाउन सक्छ भनी प्रमाणित गर्न पर्याप्त छैन।

सही ह्यान्डलरले अस्वीकृत तीही प्रमाणहरू अनन्तकालसम्म फेरि प्रयास गर्नबाट पनि बच्नुपर्छ। खाता दिएपछि आउने दोस्रो चुनौतीलाई पासवर्ड सधैं फेरि बजाउने अनुरोध होइन, बरु अनुसन्धानका लागि प्रमाणको रूपमा लिनुहोस्।

प्रमाणहरू एक्सटेन्सनको उपयुक्त सुरक्षित ह्यान्डलिङ मार्गमै रहनुपर्छ। तिनीहरूलाई PAC फाइलमा प्रकाशित नगर्नुहोस् वा वितरित नमुनामा हार्डकोड नगर्नुहोस्। लक्ष्य साँघुरो दायराको प्रोक्सी लगइन हो, हरेक प्रमाणीकरण चुनौतीलाई एउटै गोप्य कुराले जवाफ दिने ब्राउजर-व्यापी नियम होइन।

सम्बन्धित लेखहरू