Chrome onAuthRequired: בדוק את isProxy לפני שליחת פרטי גישה
קריאת החזרה של האימות ב-Chrome יכולה לתאר אתגר פרוקסי או אתגר מקור. מסירת אותם פרטי גישה לשניהם היא באג בהיקף פרטי הגישה.
תוסף דפדפן יכול להיתקל באתגרי אימות משני מקומות שונים: הפרוקסי שנושא את הבקשה ואתר היעד. אסור ששניהם יקבלו אוטומטית את אותו חשבון.
המבחין השימושי באירוע webRequest.onAuthRequired של Chrome הוא isProxy. קריאת חזרה שמסירה את הבדיקה הזו רק כדי שבקשה תיעלם עלולה להתחיל לספק פרטי גישה של פרוקסי לאתגר מקור.
התאם לפרוקסי שבו אתה מתכוון לבטוח
בדיקת isProxy היא התחלה. הגבל גם את הטיפול למאתגר הפרוקסי הצפוי ולהקשר הבקשה. תוסף שמנהל כמה נקודות קצה צריך לבחור את החשבון השייך לאותה נקודת קצה, ולא סיסמה גלובלית אחת לכל אתגר.
אל תניח שהגדרת מסלול הפרוקסי וטיפול בהתחברות שלו הם הרשאה אחת או קריאת API אחת. Chrome מתעד אותם בנפרד. השתמש בהפניה הנוכחית של webRequest לנתוני אירועים ולהרשאות אימות. דוגמה לרישום מאזין Manifest V3 מציגה רישום סינכרוני ובחירת חשבון בתוך קריאת החזרה.
בדוק את דור המניפסט
דוגמאות שמזכירות API WebRequest ניסיוני מגיעות מגרסאות תוסף ישנות. דרישות ההרשאה הנוכחיות תלויות בדור המניפסט של התוסף ובמודל הפריסה. במיוחד, לטיפול באימות יש מסלול הרשאה נתמך משלו; דוגמה מיושנת של מאזין חוסם אינה מספיקה כדי לקבוע שתוסף Manifest V3 יכול להריץ אותה ללא שינוי.
מטפל נכון חייב גם להימנע מניסיון חוזר אינסופי של אותם פרטי גישה שנדחו. התייחס לאתגר שני לאחר מסירת חשבון כראיה לחקירה, ולא כבקשה לנגן את הסיסמה לנצח.
פרטי גישה צריכים להישאר במסלול הטיפול המוגן המתאים של התוסף. אל תפרסם אותם בקובץ PAC ואל תקודד אותם בקשיחות בדוגמה מופצת. המטרה היא התחברות פרוקסי בהיקף צר, לא כלל ברמת הדפדפן שעונה לכל אתגר אימות באותו סוד.