תוספי Chrome: קראו בחזרה את תצורת ה-proxy האפקטיבית
בדקו השלמה, value.mode, levelOfControl והיקף לפני שאתם מתייחסים לקריאה החוזרת של set כהוכחה לנתיב בפועל של הדפדפן.
השלמה מוצלחת של settings.set() אומרת פחות מבקשת דפדפן מוצלחת דרך נקודת הקצה המיועדת. קראו בחזרה את ה-ChromeSetting האפקטיבי לאחר שהפעולה האסינכרונית מסתיימת, וטפלו קודם בנתיב השגיאה שלה.
| פרט הקריאה החוזרת | השאלה שהיא עונה עליה |
|---|---|
value.mode | האם זו תצורת מערכת, שרתים קבועים או PAC? קראו את השדות המתאימים לצורה הזו במקום להניח מארח ברמה העליונה. |
levelOfControl | האם תוסף זה יכול לשלוט בהגדרה, והאם הוא נשלט על ידי תוסף זה או אחר? מדיניות מנוהלת יכולה להגביל שינויים. |
| היקף והקשר גלישה | האם אתם בודקים את הסידור הרגיל או את סידור הגלישה בסתר המיועד? השתמשו באפשרויות הקריאה והכתיבה המתועדות של ה-API. |
קריאה שהופעלה מיד לאחר תחילת פעולת set עלולה להתחרות בה. קריאה של מאפיין שגוי עלולה לגרום לתצורת מערכת או PAC תקפה להיראות ריקה. אף אחת מהתצפיות אינה מוכיחה שה-proxy המרוחק דחה משהו.
אם בקרת הגדרות מושבתת, בדקו את המדיניות או התוסף השולט במקום לכתוב שוב ושוב למאגר מתחרה. Chrome יכול לשלב הגדרות מערכת, תצורת שורת פקודה, תוספים ומדיניות.
לאחר שהתצורה האפקטיבית מובנת, בדקו את הנתיב אל היעד. PAC או עקיפה עשויים לבחור במכוון בגישה ישירה. אם הוא בוחר ב-proxy הצפוי, זמינות נקודת הקצה, האימות והיציאה הנצפית נשארות שאלות לבקשת הדפדפן בפועל; קריאה חוזרת של התצורה אינה בדיקת תקינות.