אחסון במטמון HTTP: הגנה על תגובות מותאמות אישית

מה מדריך זה עוזר להשיג

• שכבות מלאי
• בחירת שמירה
• בדיקת מפתחות
• אימות מחדש ושינוי תרגיל

בדיקה מהירה

• האם אי-מטמון פירושו ששום דבר לא נשמר?
• האם Vary מגן על זכויות גישה?
• האם כל API צריך להיות מאוחסן במטמון?

שיטה שלב אחר שלב

1. 1

   שכבות מלאי

   רשימת מטמוני דפדפן, CDN, פרוקסי, עובד שירות ויישומים. סיווג תגובות ציבוריות ומותאמות אישית. מדיניות HTTP אינה מתארת ​​​​באופן אוטומטי אחסון במטמון המיועד בקוד.

   תוצר: דיאגרמת שכבות ובעלים.

2. 2

   בחירת שמירה

   RFC 9111 מבחין בין הנחיות: ללא מטמון דורש אימות לפני שימוש חוזר, ללא אחסון אוסר על אחסון HTTP רלוונטי, ופרטי לא מוסמך אינו כולל אחסון משותף. אף אחד מהם לבדו מבטיח סודיות מערכת.

   תוצר: מדיניות שמירה לכל תגובה.

3. 3

   בדיקת מפתחות

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

   תוצר: מפתחות ובדיקות הפרדה.

4. 4

   אימות מחדש ושינוי תרגיל

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

   תוצר: עקבות לפני ואחרי.

5. 5

   הפעלה חוזרת עם שני חשבונות.

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

   תוצר: בדיקות שליליות ואסטרטגיית פסילה.

גליון עבודה לשימוש חוזר

מלאו את התצפיות המאושרות שלכם. שדות אלה הם תבנית עבודה, לא תוצאות שנצפו.

הבחנה בין המנגנונים

מדדי ניהול

טעויות נפוצות

• אין לקרוא אותו כלא אחסון
• אין לקרוא אותו כהבטחת סודיות
• בדיקת מטמוני יישומים והיסטוריה בנפרד