שליטה ברישום אפליקציות Entra ID מרובי דיירים עבור SPFx

By Mirko Peters · 2026-08-11

ברוכים השבים לפודקאסט! אם ניסיתם פעם לקחת פתרון SPFx שנבנה בקפידה בדייר הפיתוח שלכם ולפרוס אותו בסביבת לקוח, אתם כבר מכירים את תחושת הירידה בלב כשהכול קורס. שקט. רכיבי Web ריקים. לולאות התחברות אינסופיות. אימות חוצה דיירים הוא המבחן האולטימטיבי למפתחי Microsoft 365, והצלחה בו דורשת שליטה בפרטים של רישומי אפליקציות Entra ID, היקפים דינמיים ואבטחה עם הרשאות מינימליות.

Automatically translated with AI from the original post. Read the English original

Titelbild: Mastering Multi-Tenant Entra ID App Registrations for SPFx

במדריך מקיף זה אנו מרחיבים על כל מה שדנו בו בפרק האחרון שלנו. להעמקה בשיחה הקולית, האזינו לפירוט המלא שלנו בנושא Fix Multi-Tenant SPFx Authentication.

מבוא: למה SPFx מרובה דיירים הוא מצב "הארד מוד"

העברת אפליקציית SPFx בין גבולות זהות נחשבת לעיתים קרובות ל"הארד מוד" מסיבה טובה. כשבונים בתוך דייר יחיד, Entra ID, מבני אתרי SharePoint והרשאות API הם במידה רבה מובנים מראש או ניתנים לעקיפה בקלות באמצעות הרשאות מנהל גלובלי. ברגע שנכנסים למודל מרובה דיירים – בין אם אתם ספק תוכנה עצמאי (ISV) שמפיץ רכיב Web, ובין אם צוות IT פנימי שמנהל מספר דיירים של חברות בנות – הקיצורים האלה נעלמים.

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

למי זה מיועד

לפני שנצלול למכניקה הטכנית, בואו נזהה מי צריך לשלוט בתבנית הארכיטקטונית הזו:

מפתחי SPFx ויועצי Microsoft 365 שמפרסמים לדיירים מרובים שרוצים להימנע מהגדרה ידנית מחדש עבור כל פריסת לקוח.
מנהלי IT וספקי MSP התומכים בסביבות SharePoint Online של לקוחות שצריכים לשמור על תנוחת אבטחה הדוקה תוך מתן פתרונות מפתחים מודרניים.
שותפים וספקי ISV שמפיצים רכיבי Web והרחבות של SPFx שזקוקים לנתיב שיווק חוזר וניתן להרחבה לאורך מאות דיירי לקוחות שונים.

עיקרי הדברים

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

אימות אינו קוד סטנדרטי: השתמשו באפליקציית Entra ID מרובת דיירים ודרשו הסכמת מנהל לכל דייר; אמתו את מצבי האבטחה האלה בזמן ריצה.
לעולם אל תקודדו פרטי דייר בקוד: טענו כתובות URL, מזהים והיקפים באופן דינמי ממקור תצורה המודע לדיירים; אחסנו סודות backend הנדרשים בצורה בטוחה ב-Azure Key Vault.
תוצאות "ריקות" מ-Graph אינן אומרות שהקוד שבור: כאשר Microsoft Graph מחזיר מערכים ריקים, הסיבה כמעט תמיד היא הסכמה חסרה או נתוני ספרייה ומסננים לא תואמים, ולא שגיאת תחביר בקוד.
חבילה אחת, דיירים רבים: תכננו את פתרונות SPFx שלכם כך שיהיו בלתי תלויים לחלוטין בדייר, בשילוב עם פריסות המוגבלות לכל דייר, כדי לבטל בנייה מותאמת אישית לכל לקוח.
ראו כשלים מוקדם: ריכזו טלמטריה ובדיקות תקינות באמצעות Application Insights או Azure Monitor המותאמים לכל דייר.

עיקרי הדברים בקצרה

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

שלוש טעויות האימות שמפילות פריסות חוצות דיירים, כולל רישומי אפליקציות מדייר יחיד, המיתוס של הסכמה חד-פעמית, והטמעת סודות ישירות בקוד צד-לקוח.
מדוע Microsoft Graph עובד בחלקות בדייר הפיתוח שלכם אך מחזיר אפס מוחלט בסביבת לקוח – וכיצד לאמת זאת לפני עליית המערכת לייצור.
אריזה פעם אחת, הגדרה בכל מקום: שרטוט הארכיטקטורה ל-SPFx באמת בלתי תלוי בדייר.
אסטרטגיות רישום וניטור שתופסות בעיות תצורה שקטות לפני שהלקוחות שלכם בכלל שמים לב אליהן.
מבני ממשל ששומרים על הארגון שלכם תואם תקנות תוך שמירה על קצב מסירה גבוה.

רשימת בדיקה מהירה (העתק/הדבק)

רישום אפליקציית Entra ID
- הגדירו סוגי חשבונות נתמכים: Multitenant.
- הגדירו את היקפי Graph מואצלים המדויקים הנדרשים, תוך מעקב אחר עיקרון הרשאות המינימום.
- הגדירו כתובות הפניה (redirect URIs) תקפות, המכסות גם את SharePoint Online וגם את סביבות הפיתוח המקומיות שלכם.
הקשחת פרויקט SPFx
- השתמשו ב-MSGraphClient או ב-AadHttpClient בכל קריאות ה-API המואצלות.
- קראו הגדרות ספציפיות לדייר (כגון נקודות קצה ומזהי אתרי יעד) מרשימת הגדרות ייעודית ב-SharePoint או מ-API מאובטח, וודאו שאין ולו סוד אחד בקוד הצד הלקוח.
- הטמיעו בדיקות הרשאות בזמן ריצה, כך שכאשר חסרות הרשאות יוצג בצורה מסודרת באנר "נדרשת הסכמת מנהל", הכולל קישור ישיר לתהליך ההסכמה.
תהליך הסכמה
- ספקו עמוד onboarding ייעודי לדייר, המציג את ההיקפים הנדרשים, כתובת הסכמת המנהל המדויקת ושלבי אימות.
- תמכו במודלים של הסכמה לפי קהל יעד, תוך הבחנה בין השקה ארגונית רחבה לבין קבוצת פיילוט ממוקדת.
אריזה ופריסה
- ארזו את הפתרון פעם אחת לקובץ .sppkg סטנדרטי, והפעילו פריסה ברמת הדייר במקומות שבהם זה מתאים.
- פרסמו דרך App Catalog מרכזי, ותעדו היטב את שלבי ההוספה ברמת האתר.
- אוטומטו את מחזור השחרור באמצעות צינור CI/CD איתן (build, bundle, package, upload ו-deploy).
ניטור ותמיכה
- שלחו טלמטריה מפורטת הכוללת Tenant ID, מזהה מתאם (correlation ID), תכונות ספציפיות וקודי שגיאה.
- חברו Application Insights או לוחות מחוונים של Azure Monitor, בצירוף התראות הניתנות לפעולה.
- תעדו נוהל חזרה לאחור ברור באמצעות גרסאות חבילה קודמות, יחד עם מפת גרסאות מפורטת לכל דייר.

מלכודות נפוצות (ופתרונות)

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

תסמין: לולאות התחברות, או התרחיש המתסכל של "עובד אצלי, לא אצלם".
סיבה: רישום האפליקציה שלכם ב-Entra ID עדיין מוגדר כדייר יחיד, או ש-reply URLs אינן תואמות לסביבת היעד.
פתרון: שנו את רישום האפליקציה למצב מרובה דיירים, תקנו את ה-redirect URIs והפעילו בקשת הסכמה חדשה.
תסמין: Microsoft Graph מחזיר מערכי נתונים ריקים לחלוטין.
סיבה: חסרה הסכמת מנהל הדייר, או שקיימים מסנני מדריך מגבילים מדי.
פתרון: הפעילו את תהליך הסכמת המנהל המתאים, בדקו את השאילתות ישירות ב-Graph Explorer באמצעות משתמש אמיתי מדייר הלקוח, והסירו הנחות מגבילות או מסננים נוקשים מהקוד.
תסמין: משתמשים אינם יכולים להוסיף את ה-web part לדפים שלהם.
סיבה: החבילה לא נפרסה כראוי ל-App Catalog של הדייר, או שמדיניות אפליקציות ארגונית חוסמת אותה.
פתרון: ודאו את סטטוס הפריסה ב-App Catalog, ובדקו את הגדרות האפליקציות והמדיניות של הדייר.
תסמין: צורך לבנות מחדש את החבילה עבור כל שינוי תצורה קטן אצל לקוחות שונים.
סיבה: מזהים, כתובות URL או סודות קשיחים מוטמעים ישירות בחבילה.
פתרון: הוציאו את התצורה החוצה מהקוד; הסתמכו על רשימות הגדרות ב-SharePoint או על Azure Key Vault, וקראו את הערכים באופן דינמי בזמן ריצה.

ממשל ואבטחה: היסודות

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

אכפו היקפים לפי עיקרון הרשאות המינימום, ובצעו סקירות היקפים קבועות להסרת הרשאות שאינן בשימוש.
אחסנו סודות של אפליקציות backend באופן מאובטח ב-Azure Key Vault, וקבעו לוח זמנים קבוע לרוטציה שלהם.
נצלו מדיניות הרשאות אפליקציות של Teams ושל SharePoint כדי להגביל בחוזקה את קהלי היעד ולמנוע שימוש לא מורשה.
נהלו פנקס הסכמות מקיף שמתעד מי נתן הסכמה, מתי ניתנה ההסכמה, ואילו היקפים אושרו.
התאימו את המיתוג של ה-web part באופן דינמי באמצעות ממשקי ה-API של ערכת הנושא של Microsoft 365, במקום לארוז נכסי עיצוב ספציפיים לדייר בתוך הקוד.

תוכנית אימות (לפני מעבר ללקוח לייצור)

לעולם אל תפרסו באופן עיוור. עברו על תוכנית האימות הזו לפני הצגת הפתרון ללקוח:

בדקו את כל קריאות Microsoft Graph ישירות בתוך דייר הלקוח באמצעות Graph Explorer, תחת אותו משתמש בדיוק ואותם היקפים מואצלים.
הריצו פריסת פיילוט מקומית על אתר יחיד ומבודד (site collection) עם קבוצה קטנה של משתמשים ממוקדים.
אמתו את היסטוריית הגרסאות ואת יכולות השחזור ישירות בתוך קטלוג היישומים של SharePoint.
תריצו תרחישים של מצב לא מקוון ושל טוקנים שפג תוקפם, כדי לוודא שהודעות השגיאה ותהליכי ההתאוששות האוטומטית פועלים כמצופה.

שאלות נפוצות

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

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

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

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

סיכום

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

כדי לשמוע עוד על סיפורי השטח והחלטות הארכיטקטורה שמאחורי הפתרונות האלה, כדאי לצפות בפרק הפודקאסט הקשור: Fix Multi-Tenant SPFx Authentication. תודה על הקריאה, ובהצלחה בקוד!