streamalism.org

1. סקירה כללית

במדריך קצר זה, אנו נלמד כיצד לפתור את השגיאה "לתגובת preflight יש קוד מצב HTTP לא חוקי 401", שיכולה להתרחש ביישומים התומכים בתקשורת מקורית ומשתמשים באביב באבטחה.

ראשית נראה מהן בקשות מוצא ואז נתקן דוגמא בעייתית.

2. בקשות מקוריות

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

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

הצעד הראשון ב- CORS הוא אפשרויות בקשה לקבוע אם יעד הבקשה תומך בכך. זה נקרא בקשה לפני הטיסה.

לאחר מכן השרת יכול לענות לבקשה לפני הטיסה באמצעות אוסף כותרות:

• בקרת גישה-אפשר-מקור: מגדיר לאילו מקורות יש גישה למשאב. '*' מייצג כל מקור
• שיטות גישה לבקרת גישה: מציין את שיטות ה- HTTP המותרות לבקשות מקוריות
• כותרות בקרת גישה - אפשר: מציין את כותרות הבקשות המותרות לבקשות מקוריות
• בקרת גישה-מקס-גיל: מגדיר את זמן התפוגה של התוצאה של בקשת ההקדמה לשמירה במטמון

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

קל להוסיף תמיכה של CORS לשירות המופעל על ידי אביב, אך אם מוגדר באופן שגוי, בקשת טרום טיסה זו תיכשל תמיד עם 401.

3. יצירת ממשק REST API המותאם ל- CORS

כדי לדמות את הבעיה, בואו ניצור תחילה ממש API פשוט של REST התומך בבקשות מקוריות:

@RestController @CrossOrigin ("// localhost: 4200") מחלקה ציבורית ResourceController {@GetMapping ("/ user") משתמש מחרוזת ציבורי (מנהל ראשי) {return principal.getName (); }}

ה @ CrossOrigin ביאור מוודא שממשקי ה- API שלנו נגישים רק מהמקור שמוזכר בטיעון.

4. אבטחת ה- REST API שלנו

בואו כעת נאבטח את ה- REST API שלנו עם Spring Security:

@EnableWebSecurity המחלקה הציבורית WebSecurityConfig מרחיב את WebSecurityConfigurerAdapter {@Override מוגן חלל להגדיר (HttpSecurity http) זורק חריג {http .authorizeRequests () .anyRequest (). מאומת () .and () .httpBasic (); }}

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

5. הגשת בקשה לפני טיסה

עכשיו, כשיצרנו את ה- REST API שלנו, בואו ננסה בקשה לפני הטיסה באמצעות סִלְסוּל:

סלסול -v -H "בקרת גישה-בקשת-שיטה: קבל" -H "מקור: // localhost: 4200" -X אפשרויות // localhost: 8080 / משתמש ... <HTTP / 1.1 401 ... <WWW -אמת: ממלכה בסיסית = "ממלכה" ... <משתנה: מוצא <משתנה: בקרת גישה-בקשת-שיטה <משתנה: בקרת גישה-בקשות-כותרות <בקרת גישה-אפשר-מקור: // localhost: 4200 <שיטות גישה-בקרה-אפשר: POST <בקרת-גישה-אישורים-אישורים: נכון <אפשר: קבל, כותרת, פוסט, שים, מחק, עקוב, אפשרויות, תיקון ...

מהפלט של פקודה זו אנו יכולים לראות זאת הבקשה נדחתה עם 401.

מכיוון שזה א סִלְסוּל פקודה, לא נראה את השגיאה "תגובה עבור preflight כוללת קוד מצב HTTP לא חוקי 401" בפלט.

אך אנו יכולים לשחזר את השגיאה המדויקת הזו על ידי יצירת יישום חזיתי שצורך את ה- REST API שלנו מתחום אחר ומריץ אותו בדפדפן.

6. הפיתרון

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

כתוצאה, ה- API שלנו מצפה לאסימון הרשאה גם בבקשת OPTIONS.

Spring מספק פתרון מהקופסה כדי לא לכלול בקשות OPTIONS מבדיקות הרשאה:

@EnableWebSecurity המחלקה הציבורית WebSecurityConfig מרחיב את WebSecurityConfigurerAdapter {@Override מוגן חלל להגדיר (HttpSecurity http) זורק חריג {// ... http.cors (); }}

ה cors () השיטה תוסיף את האביב שסופק CorsFilter להקשר היישום שעוקף בתורו את בדיקות ההרשאה לבקשות OPTIONS.

עכשיו נוכל לבדוק את היישום שלנו שוב ולראות שהוא עובד.

7. מסקנה

במאמר קצר זה, למדנו כיצד לתקן את השגיאה "לתגובת preflight יש קוד סטטוס HTTP לא חוקי 401" המקושר לבקשת אבטחה של Spring ובקשות מקוריות.

שים לב, לדוגמא, הלקוח ו- API צריכים לפעול על תחומים או יציאות שונים כדי ליצור מחדש את הבעיה. למשל, אנו יכולים למפות את שם המארח המוגדר כברירת מחדל ללקוח ואת כתובת ה- IP של המחשב ל- REST API שלנו כאשר אנו פועלים במחשב מקומי.

כמו תמיד, ניתן למצוא את הדוגמא המוצגת במדריך זה ב- Github.