לקוח אינו יכול לבחור מנגנון אימות מתוך מספר סטטוס בלבד. התגובה של הפרוקסי צריכה לתאר מה הוא מקבל.

HTTP מחייב פרוקסי שמייצר 407 לשלוח אתגר Proxy-Authenticate. עבור שירות Basic דוגמה פשוטה היא:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

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

בדקו את התגובה שהגיעה ללקוח הזה

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

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

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

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

מאמרים קשורים