כניסה ל-Salesforce CLI דרך VPN: CLI, דפדפן ומארח API
ה-CLI, הדפדפן והקריאה המאוחרת ל-API יכולים לרוץ בשלושה מארחים שונים. תנו שם לכל אחד מהם לפני שאתם מאשימים את המנהרה, את הארגון או את האסימון השמור במטמון.
כשלי כניסה ל-Salesforce CLI מדווחים כבעיה אחת והם בדרך כלל שלוש. תהליך ה-CLI רץ במקום כלשהו, הדפדפן שמשלים את זרימת האינטרנט רץ במקום כלשהו, והקריאה המאוחרת ל-API רצה במקום כלשהו, ושלושת המקומות האלה לא חייבים לחלוק נתיב, פותר או רשימת היתרים. השוואה ביניהם היא הדרך המהירה ביותר לגלות איזה מהם המנהרה באמת חוסמת. שום דבר בפלט הכניסה לא אומר איזה מן השלושה נכשל.
שלושה מארחים, סיפור כניסה אחד
זרימת הכניסה באינטרנט מעבירה את שלב הזהות לדפדפן, והדפדפן הזה נמצא לעתים קרובות במחשב הנייד שלכם בזמן שה-CLI יושב על מארח פיתוח מרוחק או בתוך מכולה. למחשב הנייד יש את לקוח ה-VPN, למארח המרוחק יש את מה שצוות הפלטפורמה נתן לו, ואף אחד משני הסידורים לא מכסה את השני אוטומטית. סמל VPN בשורת המצב לא אומר דבר על מארח שמעולם לא הריץ את הלקוח.
לאחר הכניסה, ה-CLI מבצע את בקשות ה-API שלו מהמקום שבו התהליך חי. הבקשות האלה זקוקות ל-DNS, לניתוב, לאמון TLS ולהרשאה בצד הלקוח של הארגון, שהם ארבע בדיקות נפרדות וכל אחת יכולה להיכשל בעצמה. דפדפן שנכנס יפה לא אומר לכם דבר על אף אחת מהן.
החזיקו את שני החצאים על ציר זמן אחד, אבל דרגו אותם בנפרד. אז כרטיס אחד יכול לומר איזה חצי נשבר בלי להפוך את זה לוויכוח על בעלות.
קחו את רשומת הארגון מהארגון, לא מהזיכרון
זרימת האינטרנט לוקחת כתובת URL של מופע ושומרת את התוצאה תחת כינוי, ושתי הערכים צריכים לבוא מבעל הארגון ולא מהיסטוריית הטרמינל של עמית. מארח sandbox שהועתק מכרטיס ישן הוא סיבה נפוצה לכניסה שמאמתת מול הארגון הלא נכון ואז נכשלת בכל שאילתה.
השתמשו בצורה שהתוסף המותקן מתעד, עם המארח והכינוי המאושרים שלכם. התיעוד הזה הוא ההפניה לדגלים שהשתנו בין sfdx ל-CLI הנוכחי.
sf org login web --instance-url https://acme--uat.sandbox.my.salesforce.com --alias uat
sf org display --target-org uatשם המארח והכינוי שלמעלה הם דוגמאות, לא ברירות מחדל שעליכם להעתיק. השלימו את שלבי הזהות והאימות הדו-גורמי הרגילים בדפדפן במקום לעקוף אותם בסקריפט, ולעולם אל תשימו סיסמה, מזהה הפעלה או זרע אימות בפקודת מעטפת כדי לדלג על ההנחיה.
מה מוכיח ההרשאה השמורה במטמון
כינוי שמופיע ברשימת ההרשאות המקומית מוכיח שכניסה הצליחה פעם אחת במכונה ההיא. הרשימה נקראת מאחסון מקומי ואינה יוצרת קשר עם הארגון כדי לאשר שהאסימון עדיין עובד, כך שרשומה שנראית תקינה וקריאה ל-API שנדחתה יכולות שתיהן להיות נכונות. התייחסו למטמון כרשומה של העבר, לא כבדיקת קישוריות חיה. בדיקת מטמון עונה על שאלת תמיכה, אבל היא לעולם לא סוגרת חקירת קישוריות.
אותו הבדל חל על הפעלת הדפדפן. לשונית שעדיין מציגה את הארגון לא אומרת שהאסימון השמור של ה-CLI מתאים למדיניות הנוכחית, כי תוחלת החיים של האסימון, מגבלות IP וכללי אפליקציית הלקוח נאכפים בגבול ה-API.
קראו את הרשומה המקומית לפני שאתם מוחקים אותה, כי הכינוי ומארח הארגון הם שתי העובדות שהתמיכה תשאל עליהן. הסרת כינוי היא הפיכה, אבל הסרת הכינוי הלא נכון באמצע תקרית רק מוסיפה בעיה שנייה.
איפה בקשת ה-API נדחית באמת
עקבו אחר בקשה אחת מתחילתה ועד סופה וציינו איזה רכיב עונה. כשל TLS מציין בעיה שונה מ-403, שמציין בעיה שונה מפסק זמן, ופסק זמן הוא היחיד מבין השלושה שמצביע על המנהרה כחשוד הראשון. קריאת מחלקת השגיאה לפני ההודעה חוסכת הרבה ניחושים. רשמו את המחלקה לפני שאתם מריצים משהו מחדש.
הגבלות כתובת מקור הן המקרה שמייצר כניסה שעובדת ושאילתה שלא עובדת, כי זרימת הדפדפן והקריאה ל-API יכולות לצאת דרך כתובות שונות. תיקון זה ברשימת היתרים רחבה יותר הוא החלטה של בעל הארגון, לא נוחות, והוא צריך להיות הטווח הקטן ביותר שמכסה את המארח.
תעדו את הפקודה שנכשלה, את הכינוי, את מארח ההרצה ואת חתימת הזמן, והשאירו את האסימון מחוץ לכל מה שאתם מדביקים בכרטיס. אותה תמצית של ארבע שורות היא מה שבעל הארגון צריך כדי לבדוק את הצד שלו.
בדקו את הזרימה מהמארח שישתמש בה
בדקו מהמכונה שתריץ את עומס העבודה. כניסה שאומתה במחשב הנייד שלכם לא אומרת דבר על סוכן בנייה באזור רשת אחר, וההבדל הוא בדיוק מה שאתם מנסים למצוא.
השתמשו בקריאה מורשית לא מזיקה לבדיקה, ואם היא נכשלת שמרו את השגיאה הראשונה.
sf org list auth
sf org display --target-org uat
sf data query --target-org uat --query "select Id, Name from Organization"כשהכניסה מצליחה אבל השאילתה נכשלת, המועמדים שנותרו הם DNS, ניתוב, יירוט TLS ומדיניות לקוח בצד הארגון, ולכל אחד יש בעלים משלו. כשהכניסה עצמה נכשלת, הדפדפן וה-CLI כנראה לא על אותו מארח, והתיקון שייך לסידור ביניהם ולא למנהרה. האוטומציה מקבלת כלל נוסף: משימה ללא השגחה זקוקה לכניסה מאושרת מבוססת תעודה, כי הפעלה אינטראקטיבית שמורה במטמון והועתקה לעובד אינה עיצוב זהות.