Chrome onAuthRequired: د اعتبارنامې له لېږلو مخکې isProxy وګورئ

د براوزر ضمیمه ممکن له دوه مختلف ځایونو څخه د تصدیق ننګونو سره مخ شي: هغه پراکسي چې غوښتنه وړي او د موخې وېبسایټ. دوی باید په اتوماتيک ډول یو شان حساب ترلاسه نه کړي.

په Chrome کې د webRequest.onAuthRequired پیښې کې ګټور توپیر isProxy دی. هغه غبرګون چې یوازې د دې لپاره چې یو پوښتنه ورک شي دا څېړنه لرې کوي، ممکن د پراکسي اعتبارنامه د اصل ننګونې ته ورکول پیل کړي.

له هغه پراکسي سره سمون وکړئ چې غواړئ باور پرې وکړئ

د isProxy څېړل یو پیل دی. همدارنګه د پروسس کول په تمه شوي پراکسي ننګوونکي او د غوښتنې په شرایطو محدود کړئ. هغه ضمیمه چې څو پای ټکي مدیریت کوي باید د هغه پای ټکي حساب وټاکي، نه د هرې ننګونې لپاره یو نړیوال پټنوم.

مه فکر کوئ چې د پراکسي لارې ټاکل او د هغې د ننوتلو پروسس کول یو اجازه یا یو API کال دي. Chrome دواړه په جلا توګه مستند کوي. د پیښې معلوماتو او د تصدیق اجازو لپاره د webRequest اوسنی حواله وکاروئ. د Manifest V3 اورېدونکي د راجستر مثال د غبرګون په داخل کې همغږي راجستر او د حساب ټاکنه ښیي.

د manifest نسل وګورئ

هغه مثالونه چې تجربي WebRequest API یادوي له زوړ ضمیمې خپرونو څخه راځي. اوسني د اجازې غوښتنې د ضمیمې د manifest نسل او د ځای پرځای کولو ماډل پورې اړه لري. په ځانګړي ډول، د تصدیق پروسس خپله ملاتړ شوې د اجازې لاره لري؛ یو زوړ بندونکی اورېدونکی مثال د دې لپاره بس نه دی چې ثابت کړي Manifest V3 ضمیمه کولای شي دا پرته له بدلون څخه چل کړي.

سمونګر باید له هماغو رد شوو اعتبارنامو څخه د بې پایه بیا هڅې هم ډډه وکړي. له حساب ورکولو وروسته دوهمه ننګونه د پټنوم د تل لپاره بیا غږولو غوښتنه نه، بلکې د څېړنې لپاره شواهد وګڼئ.

اعتبارنامه باید د ضمیمې په مناسبه ساتل شوې د پروسس لاره کې پاتې شي. هغه په PAC فایل کې خپاره نه کړئ او په وېشل شوي نمونه کې یې کلک کوډ مه کوئ. موخه د پراکسي تنګه محدوده ننوتنه ده، نه د ټول براوزر قاعده چې هرې تصدیق ننګونې ته په ورته راز ځواب وایي.