إتقان تدفق موافقة المسؤول لحلول Microsoft 365 متعددة المستأجرين

By Mirko Peters · 2026-08-11

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

Titelbild: Mastering the Admin-Consent Flow for Multi-Tenant Microsoft 365 Solutions

مرحبًا بكم مجددًا في المدونة! إذا سبق لكم أن حاولتم نقل حل مخصص لإطار عمل SharePoint (SPFx) من مستأجر التطوير الخاص بكم إلى بيئة الإنتاج لدى أحد العملاء، فأنتم تعرفون الشعور المحبط عندما تتعطل الأمور بصمت. يُعد تطوير حلول Microsoft 365 متعددة المستأجرين مهمةً صعبةً بشكل معروف. فحدود الهوية، ومعايير الأمان، وبنى المواقع الخاصة بكل مستأجر، وعوائق الموافقة، كلها قادرة على تحويل عملية نشر روتينية إلى كابوس حقيقي. لهذا السبب نتعمق اليوم في إتقان تدفق موافقة المسؤول لحلول متعددة المستأجرين. وإذا كنتم ترغبون في الاستماع إلى النقاش الصوتي بتفصيل أكبر، فتأكدوا من الاطلاع على حلقة البودكاست ذات الصلة، Fix Multi-Tenant SPFx Authentication، حيث نفصّل هذه السيناريوهات تحديدًا.

في هذه المقالة، سنستعرض كيفية إعداد تطبيقاتكم بالشكل الصحيح، وكيفية إرشاد عملائكم خلال عملية تسجيل المستأجر وموافقة المسؤول دون إحداث أي عرقلة، وكيفية التعامل مع نطاقات Microsoft Graph المفوَّضة لتجنب مجموعات البيانات الفارغة، وكيفية بناء لافتات أذونات وحالات أخطاء أثناء التشغيل تتعامل معها بسلاسة. لنجعل تطوير الحلول متعددة المستأجرين قابلًا للتنبؤ وآمنًا وقابلًا للتكرار.

لمن هذا الدليل؟

كُتب هذا الدليل خصيصًا للمحترفين الذين يعملون عبر بيئات متعددة من Microsoft 365 ويحتاجون إلى بنى موثوقة قابلة للتوسع. وستجدونه مفيدًا للغاية إذا كنتم:

مطوّرين لإطار SPFx ومستشارين في Microsoft 365 يقدمون مكونات مخصصة لمستأجرين متعددين من العملاء.
مسؤولي تقنية المعلومات ومزودي الخدمات المُدارة (MSPs) الذين يدعمون بيئات SharePoint Online وEntra ID لدى العملاء.
شركاء البرمجيات ومزودي البرمجيات المستقلين (ISVs) الذين يحوّلون أجزاء ويب SPFx والامتدادات والإضافات إلى منتجات قابلة للتوزيع التجاري.

المصادقة ليست قالبًا جاهزًا: إعداد تطبيق Entra ID متعدد المستأجرين

من أخطر الفخاخ التي يقع فيها المطوّرون اعتبار المصادقة مجرد شيفرة نموذجية تُنسخ وتُلصق من مشروع إلى آخر. فعند بناء حل مخصص للعمل عبر عدة مؤسسات، يجب ضبط تسجيل تطبيق Entra ID (المعروف سابقًا باسم Azure AD) صراحةً ليدعم تعدد المستأجرين.

إذا تُرك تسجيل التطبيق عن طريق الخطأ على مستأجر واحد، فسيواجه المستخدمون الذين ينتمون إلى خارج مؤسستكم حلقات تسجيل دخول متكررة أو إخفاقات في الأذونات فورًا. ولإصلاح ذلك، تأكدوا من ضبط أنواع الحسابات المدعومة في تسجيل التطبيق لتكون "حسابات في أي دليل مؤسسي (متعدد المستأجرين)". وإضافةً إلى ذلك، عرّفوا نطاقات Graph المفوَّضة الدقيقة التي يحتاجها حلكم وفق مبدأ أقل الامتيازات، واضبطوا عناوين URI لإعادة التوجيه بدقة بحيث تشمل نطاقات SharePoint Online وبيئة التطوير المحلية لديكم.

بناء تجربة تسجيل وموافقة مسؤول موجّهة وسلسة

قد يؤدي توقّع أن يتعامل مستخدمو الأعمال اليوميون مع مطالبات الموافقة بأنفسهم إلى تعطيل عملية الإطلاق. والأسوأ من ذلك أن توقّع أن يثق مسؤولو تقنية المعلومات لدى العميل بمطالبة غير موجّهة دون تردد غالبًا ما يؤدي إلى حظر عمليات التثبيت. ولترسيخ الثقة وتبسيط الاعتماد، تحتاجون إلى بناء صفحة تسجيل موجّهة.

تقدم تجربة التسجيل الاحترافية لمسؤولي العميل نظرة واضحة على النطاقات المطلوبة، وعنوان URL دقيقًا لموافقة المسؤول يبدأ توفير تطبيق المؤسسة، وتعليمات تحقق خطوة بخطوة. ومن خلال دعم الموافقة لكل فئة مستهدفة، أي السماح للمسؤولين بمنح الموافقة للمؤسسة بأكملها أو لمجموعات تجريبية محددة، فإنكم تخفضون حاجز الدخول وتزيلون عوائق النشر.

التعامل مع نطاقات Graph المفوَّضة ومنع مجموعات البيانات الفارغة

هل سبق لكم أن نشرتم جزء ويب يعمل بشكل ممتاز في بيئة التطوير لديكم، ثم وجدتم صفحات ويب فارغة تمامًا عند تثبيته في مستأجر أحد العملاء؟ هذه علامة كلاسيكية على غياب موافقة مسؤول المستأجر أو عدم تطابق بيانات الدليل.

عندما تُرجع Microsoft Graph مجموعات بيانات فارغة، فنادرًا ما يكون السبب خللًا في منطق تطبيقك. وفي معظم الحالات، يعني ذلك أن التطبيق قد نجح في المصادقة، لكن مسؤول المستأجر لم يوافق بعد على النطاقات المفوضة المطلوبة، أو أن عوامل التصفية التنظيمية للبيانات التي تطبّقها لا تتطابق مع ملفات تعريف مستخدمي العميل أو تخطيطات المواقع لديه. اختبر استعلاماتك دائمًا باستخدام Graph Explorer ضمن سياق مستخدم تمثيلي لدى العميل، وصمّم منطق تطبيقك بحيث يتعامل بسلاسة مع مجموعات البيانات الجزئية أو المفقودة بدلًا من إطلاق استثناءات غير معالجة.

إنشاء لافتات مفيدة للأذونات وقت التشغيل وحالات الخطأ

حتى مع أفضل خطط الإعداد، قد يُغفل المسؤولون أحيانًا نطاقًا ما، أو يسحبون أذونات لاحقًا. وعند حدوث ذلك، لا ينبغي أن يتعطل تطبيقك أو أن يعرض خطأً غامضًا في وحدة تحكم JavaScript. بل ينبغي أن يتضمن لافتات مفيدة للأذونات وقت التشغيل، وحالات خطأ سياقية.

من خلال التحقق من الأذونات بشكل غير متزامن أثناء التشغيل، يمكن لمكوّنات الويب في SPFx أن تكتشف فورًا نطاق الرمز المميّز غير الصالح أو المفقود. وعند اكتشاف نقص ما، اعرض لافتة واضحة واحترافية تنبّه المستخدم إلى أن الموافقة الإدارية مطلوبة، مع رابط مباشر إلى عنوان الإعداد الإرشادي أو عنوان الموافقة لديك. هذا يحوّل تذكرة دعم مُحبِطة إلى حل ذاتي يُنجزه العميل بنفسه.

فصل الإعدادات عن الحزمة وإبقاء حزمة SPFx خالية من الأسرار

إن تضمين معرّفات المستأجر، ومعرّفات العملاء، ونقاط نهاية واجهات البرمجة، أو أسرار العملاء مباشرةً داخل حزمة SPFx يُعدّ خرقًا أمنيًا جسيمًا ومأزقًا تشغيليًا. فإذا ثبّتَّ هذه التفاصيل في الشيفرة، فستجد نفسك تدير عشرات البنى المختلفة لكل عميل تضمّه.

الأسلوب الصحيح هو تصميم حزمة SPFx بحيث تكون مستقلة تمامًا عن المستأجر. خزّن إعدادات التهيئة في موقع يدرك المستأجر، مثل قائمة إعدادات مركزية في SharePoint، أو واجهة برمجة تطبيقات خارجية، أو Azure App Configuration. وإذا كانت خدماتك الخلفية تتطلب أسرار تطبيقات، فاحفظها وأدِرها بأمان باستخدام Azure Key Vault بدلًا من تضمينها في حزم الشيفرة على جانب العميل.

النشر مرة واحدة والتوزيع في كل مكان: استراتيجية خط الأنابيب الواحد

بمجرد أن تصبح شيفرتك موجّهة بالإعدادات وخالية من الأسرار، يمكنك اعتماد استراتيجية نشر بخط أنابيب واحد. أي أن تُجمّع حلّك وتحزمه في ملف .sppkg واحد فقط، ثم تنشر الحزمة نفسها في جميع مستأجري عملائك.

وبالاستفادة من النشر المحدَّد بنطاق المستأجر عند الاقتضاء، يمكنك نشر حلّك إلى كتالوجات التطبيقات المركزية (App Catalogs)، وأتمتة خطوط CI/CD لتتولى البناء والتجميع والتعبئة والنشر دون الحاجة إلى تفرّعات يدوية للشيفرة. وهذا يبسّط إدارة الإصدارات تبسيطًا كبيرًا، ويضمن أن يشغّل كل عميل الشيفرة نفسها من تدفق الملفات الثنائية المُختبَر ذاته.

المراقبة والقياس عن بُعد، واكتشاف الأعطال مبكرًا

عندما تدير حلولًا تعمل عبر عشرات المستأجرين لدى عملاء مختلفين، لا يمكنك الاعتماد على العملاء للإبلاغ عن كل خلل. تحتاج إلى رؤية استباقية لصحة تطبيقك. ومركزة بيانات القياس عن بُعد أمر ضروري.

اضبط مكوّنات SPFx لإصدار بيانات قياس عن بُعد منظّمة، تتضمن معرّفات المستأجرين، ومعرّفات الارتباط، والميزات النشطة، ورسائل الأخطاء، وأرسلها مباشرةً إلى Application Insights أو إلى لوحات Azure Monitor. إن إعداد تنبيهات لأعطال المصادقة المتكررة أو لانتهاء مهلات Graph يتيح لفريق الهندسة لديك رصد المشكلات ومعالجتها قبل أن يلاحظها عملاؤك.

المزالق الشائعة وطرق معالجتها

حتى مع التخطيط الدقيق، تظهر عادةً بعض العقبات المرتبطة بتعدد المستأجرين بشكل متكرر. وفيما يلي أكثر الأعراض شيوعًا التي يواجهها المطورون، وكيفية إصلاحها:

العرض: حلقات تسجيل دخول، أو أخطاء تفيد بأن "الأمر يعمل مع مستأجري، لكنه لا يعمل مع مستأجرهم".
السبب: تسجيل التطبيق لديك مضبوط عن طريق الخطأ على مستأجر واحد، أو يوجد عدم تطابق في عنوان الرد (reply URL).
الحل: غيّر نوع تسجيل التطبيق إلى متعدد المستأجرين، وتحقّق من عناوين إعادة التوجيه (Redirect URIs) وحدّثها، ثم أعد تشغيل تدفق الموافقة الإدارية.
العرض: تُرجع Microsoft Graph مجموعات بيانات فارغة.
السبب: غياب موافقة مسؤول المستأجر، أو عوامل تصفية مفرطة التقييد للمستخدمين أو المجموعات.
الحل: شغّل سير عمل الموافقة الإدارية، واختبر استعلامات واجهة برمجة التطبيقات الدقيقة لديك في Graph Explorer باستخدام حساب عميل حقيقي، وخفّف عوامل تصفية الاستعلام المقيِّدة.
الأعراض: لا يستطيع المستخدمون إضافة جزء الويب إلى صفحاتهم الحديثة.
السبب: لم يتم نشر الحزمة على مستوى المستأجر، أو أن نهج التطبيقات على مستوى المؤسسة يحظرها.
الحل: تحقق من حالة نشر الحزمة في App Catalog، وراجع إعدادات تطبيقات Microsoft 365 ونهج النشر على مستوى المستأجر.
الأعراض: الحاجة إلى إعادة التجميع وإعادة بناء الحل من أجل تحديثات تهيئة بسيطة.
السبب: معرّفات أو عناوين URL أو نقاط نهاية مكتوبة بشكل ثابت في الكود.
الحل: انقل قيم التهيئة إلى قائمة SharePoint أو مخزن تهيئة آمن، واجلبها ديناميكيًا أثناء التشغيل.

الحوكمة وأساسيات الأمان ومبدأ أقل الامتيازات

العمل في بيئات المؤسسات يجعل حوكمة الأمان أمرًا لا غنى عنه. للحفاظ على أمان عملائك والالتزام بالامتثال، التزم بمبادئ الأمان الأساسية التالية:

اطلب دائمًا الحد الأدنى المطلق من النطاقات المفوضة المطلوبة، وأجرِ مراجعات منتظمة للنطاقات.
لا تخزّن الأسرار بنص عادي أبدًا؛ استخدم Azure Key Vault وقم بتدوير الأسرار وفق جدول زمني منتظم.
استخدم نهج أذونات التطبيقات في Microsoft Teams وSharePoint لتقييد ظهور التطبيق لجمهور محدد من المستخدمين.
احتفظ بسجل للموافقات يوثّق المستأجرين العملاء الذين وافقوا، ومتى تمت الموافقة، والنطاقات التي تمت الموافقة عليها.
وافق هوية العلامة التجارية البصرية مع بيئات العملاء باستخدام واجهات SharePoint البرمجية للسمات بدلًا من تضمين أصول CSS ثابتة خاصة بكل مستأجر.

خطة التحقق قبل الإطلاق لدى العميل

قبل أن تعتمد نشر العميل وتعلن النجاح، نفّذ خطة تحقق دقيقة لضمان عدم وجود مفاجآت.

اختبر استدعاءات Microsoft Graph بدقة داخل مستأجر العميل المستهدف باستخدام Graph Explorer، وبالحساب والنطاقات نفسها تمامًا.
نفّذ مرحلة تجريبية محكومة على مجموعة مواقع مخصصة واحدة مع مجموعة صغيرة من المستخدمين المستهدفين.
تحقق من سجل الإصدارات وإجراءات الاسترجاع مباشرةً داخل App Catalog في SharePoint الخاص بالعميل.
اختبر سيناريوهات فقدان الاتصال أو انتهاء صلاحية الرموز المميزة، للتأكد من أن رسائل الخطأ المخصصة وتدفقات الاسترداد تعمل بسلاسة.

الأسئلة المتداولة

هل أحتاج إلى أذونات تطبيق لـ SPFx؟

عادةً لا. يعمل SPFx بالكامل ضمن سياق المستخدم المفوَّض. تتطلب أذونات التطبيق موافقات إدارية إضافية وأنماطًا معمارية متخصصة، لذا استخدمها فقط عندما تكون المعالجة في الخلفية خارج جلسة المستخدم ضرورية.

هل يمكنني تجنب الموافقة لكل مستأجر؟

لا. يفرض نموذج الأمان لدى Microsoft أن يمنح مسؤول كل مستأجر موافقة صريحة على النطاقات التي يطلبها التطبيق متعدد المستأجرين. يمكنك تبسيط هذه العملية، لكن لا يمكنك تجاوزها تمامًا.

كيف أحافظ على قاعدة شفرة واحدة لعملاء كثيرين؟

اجعل الحل مستقلًا تمامًا عن المستأجر، وانقل بيانات التهيئة إلى خارج الكود، وأتمتة مسارات التغليف والنشر، واستخدم أعلام الميزات لإدارة الإعدادات الخاصة بكل عميل ديناميكيًا.

كيف أشخّص مشكلة "كل شيء فارغ" بشكل أسرع؟

سجّل استجابات Microsoft Graph إلى جانب فحوصات التحقق من النطاقات، واعرض إشعارًا مضمّنًا يوضح الموافقة المفقودة أو النطاق غير الكافي، مع رابط مباشر لإصلاحها فورًا.

الخاتمة

إن إتقان تدفق الموافقة الإدارية والمصادقة متعددة المستأجرين لحلول SPFx هو ما يفصل التطبيقات الهاوية عن المنتجات المؤسسية. فمن خلال إنشاء تطبيق Entra ID متعدد المستأجرين، وبناء تجارب إعداد موجّهة، ونقل التهيئة إلى خارج الكود، وتطبيق القياس عن بُعد الاستباقي، يمكنك التخلص من قلق النشر وتقديم تجارب سلسة لكل عميل. وللاستماع إلى المزيد عن تحديات الهوية هذه في الواقع العملي، تأكد من الاستماع إلى نقاشنا الكامل في الحلقة البودكاست Fix Multi-Tenant SPFx Authentication. شكرًا لقراءتك، وبالتوفيق في البرمجة!