Azure Storage Java: מסלולי פרוקסי לבקשות API ולבקשות אסימון
בדקו גם בקשות Azure Storage וגם בקשות אסימון של אישורי גישה בעת הגדרת פרוקסי של Java SDK.
הגדרת פרוקסי על תעבורת ה-HTTP של לקוח אחסון עונה על שאלה אחת: כיצד אותה תעבורה שולחת בקשות אחסון. ייתכן שלאישור זהות יש לקוח HTTP אחר להשגת אסימונים.
ההבחנה הזו מסבירה סתירה שנראית שכיחה: נקודת הקצה של האחסון נגישה דרך הפרוקסי, אך ה-SDK נכשל לפני שליחת הפעולה הצפויה. הכשל יכול להשתייך להשגת אישורים מול נקודת קצה של זהות.
תחילה תיעדו איזה יעד נכשל. לאחר מכן בדקו את לקוח ה-HTTP שהועבר לבונה האחסון ואת התצורה שבה משתמשת מימוש אישורי הגישה. פעלו לפי אפשרויות הפרוקסי הנתמכות של כל תעבורה. עבור נקודות קצה של אחסון ואסימון הנגישות לציבור במסלול פרוקסי ציבורי מורשה, רשימת פרוקסי ה-HTTP מציעה מועמדים לנקודות קצה; אל תניחו שהגדרה של בונה אחד מגדירה מחדש כל אובייקט ביישום.
| שלב | ראיות שימושיות |
|---|---|
| השגת אסימון | נקודת קצה של זהות, לקוח נבחר, אתגר פרוקסי או שגיאת חיבור |
| בקשת אחסון | נקודת קצה של אחסון, צינור מוגדר, תגובה סופית או כשל העברה |
הפרידו בין חשבון הפרוקסי לאישור Azure. התחברות מוצלחת לפרוקסי מעניקה מסלול; שירות היעד עדיין מאשר את פעולת Azure.
תשובות היסטוריות משתמשות בכמה דורות של מחלקות Azure Storage Java, כולל ממשקי OperationContext וצינור ישנים. התאימו דוגמה ל-SDK ולתעבורת ה-HTTP שבהם היישום משתמש כעת. עבור SDK של Data Lake, הגדרה משותפת של לקוח HTTP לאחסון ולזהות מציגה את שני קלטי הבונה. החזרת סוג לקוח מיושן לפתרון בעיית פרוקסי יוצרת מסלול תצורה נוסף לניפוי באגים.
השתמשו במזהי נקודות קצה בטוחים ביומנים. כתובות URL של אחסון יכולות להכיל אסימוני גישה, וכתובת URL מלאה של פרוקסי יכולה להכיל סיסמה.