אימות פרוקסי Basic ב-OkHttp: עצרו ניסיונות חוזרים שנדחו

עבור פרוקסי HTTP שמציע אימות Basic, ה-proxyAuthenticator של OkHttp יכול להחזיר בקשה הנושאת פרטי התחברות. החזירו null לאחר שניסיון הרשאה כבר נדחה, במקום לשלוח שוב את אותה תשובה:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

הסקיצה הזו משתמשת בערכי חשבון מהתצורה הסודית של היישום. השומר מאפשר ניסיון ראשוני ועוצר ניסיון חוזר. הוא מיישם Basic, לא כל סכימה שפרוקסי עשוי להכריז עליה; בדקו את האתגר לפני בחירת התשובה הזו.

אם התוצאה הסופית נשארת 407, השוו את הפרוקסי הנבחר, הסכימה המוכרזת וזהות החשבון המתועדת. סיסמה שנדחתה, שיטה לא נתמכת וצורת שם משתמש שגויה דורשות תיקונים שונים. שמרו את התצפיות האלה ואת הסטטוס הסופי באבחון מחוק.

ל-CONNECT יש הקשר קריאה חוזרת אחר: OkHttp מתעד אתגר אימות פרוקסי סינתטי מקדים לפני פתיחת המנהרה. טפלו בהקשר הזה לפי ה-API במקום להניח שכל קריאה חוזרת היא תגובת יעד רגילה.

ה-authenticator הנפרד מיועד לאימות שרת היעד. שמרו את פרטי ההתחברות שלו בנפרד מכניסת הפרוקסי; מיירט כללי שמציב סיסמת פרוקסי בכל בקשה יוצאת עלול לשלוח אותה בהיקף הלא נכון.

דוחות היסטוריים מתארים גם באגים ביישום, כולל טיפול בגוף תגובת פרוקסי שנדחתה. תעדו את גרסת OkHttp ואת החליפין הסופי לפני שתייחסו כשל נוכחי לדוח ישן. החלטת הניסיון החוזר עדיין אמורה לעצור ניסיון פרטי התחברות שלא השתנה ושאין לו תשובה חדשה שימושית.