Chrome onAuthRequired: پیش از ارسال اعتبارنامه‌ها isProxy را بررسی کنید
فراخوان تماس احراز هویت Chrome می‌تواند یک چالش پراکسی یا یک چالش مبدأ را توصیف کند. دادن همان اعتبارنامه به هر دو، خطای دامنه اعتبارنامه است.
یک افزونه مرورگر ممکن است با چالش‌های احراز هویت از دو جای متفاوت روبه‌رو شود: پراکسی‌ای که درخواست را حمل می‌کند و وب‌سایت مقصد. آن‌ها نباید به‌طور خودکار همان حساب را دریافت کنند.
تفکیک‌کننده مفید در رویداد webRequest.onAuthRequired کروم isProxy است. فراخوان تماسی که آن بررسی را فقط برای ناپدید شدن یک اعلان حذف می‌کند، ممکن است شروع به ارائه اعتبارنامه‌های پراکسی به یک چالش مبدأ کند.
با پراکسی‌ای که قصد اعتماد به آن را دارید هم‌خوان شوید
بررسی isProxy یک آغاز است. همچنین پردازش را به چالش‌گر پراکسی مورد انتظار و بافت درخواست محدود کنید. افزونه‌ای که چند نقطه پایانی را مدیریت می‌کند باید حساب متعلق به همان نقطه پایانی را انتخاب کند، نه یک گذرواژه سراسری برای هر چالش.
فرض نکنید که تنظیم مسیر پراکسی و مدیریت ورود آن یک مجوز یا یک فراخوان API است. کروم آن‌ها را جداگانه مستند می‌کند. برای داده‌های رویداد و مجوزهای احراز هویت از مرجع کنونی webRequest استفاده کنید. یک نمونه ثبت شنونده Manifest V3 ثبت همگام و انتخاب حساب را درون فراخوان نشان می‌دهد.
نسل مانیفست را بررسی کنید
نمونه‌هایی که به API آزمایشی WebRequest اشاره می‌کنند از نسخه‌های قدیمی افزونه می‌آیند. الزامات مجوز کنونی به نسل مانیفست افزونه و مدل استقرار آن بستگی دارد. به‌ویژه، مدیریت احراز هویت مسیر مجوز پشتیبانی‌شده خود را دارد؛ یک نمونه منسوخ از شنونده مسدودکننده برای اثبات اینکه افزونه Manifest V3 می‌تواند آن را بدون تغییر اجرا کند کافی نیست.
یک مدیر صحیح باید از تلاش بی‌پایان دوباره با همان اعتبارنامه‌های ردشده نیز بپرهیزد. چالش دوم پس از ارائه حساب را شواهدی برای بررسی بدانید، نه درخواستی برای پخش ابدی گذرواژه.
اعتبارنامه‌ها باید در مسیر پردازش محافظت‌شده مناسب افزونه باقی بمانند. آن‌ها را در یک فایل PAC منتشر نکنید و در یک نمونه توزیع‌شده به‌صورت سخت‌کد قرار ندهید. هدف یک ورود پراکسی با دامنه محدود است، نه قاعده‌ای در سطح مرورگر که به هر چالش احراز هویت با همان راز پاسخ دهد.