إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
توفر Azure App Service خدمة استضافة ويب قابلة للتطوير بدرجة كبيرة وذاتية التصحيح. تحتوي App Service على دعم مضمن لمصادقة المستخدم وتخويله. يوضح هذا البرنامج التعليمي كيفية تأمين التطبيقات باستخدام مصادقة وتفويض خدمة التطبيقات. ويستخدم Express.js مع الواجهة الأمامية لطرق العرض. تدعم مصادقة خدمة التطبيقات وتخويلها جميع أوقات تشغيل اللغة. يمكنك تعلم كيفية تطبيقه على لغتك المفضلة باتباع هذا البرنامج التعليمي.
توفر Azure App Service خدمة استضافة ويب قابلة للتطوير بدرجة كبيرة وذاتية التصحيح باستخدام نظام التشغيل Linux. تحتوي App Service على دعم مضمن لمصادقة المستخدم وتخويله. يوضح هذا البرنامج التعليمي كيفية تأمين التطبيقات باستخدام مصادقة وتفويض خدمة التطبيقات. ويستخدم Express.js مع الواجهة الأمامية لطرق العرض. تدعم مصادقة خدمة التطبيقات وتخويلها جميع أوقات تشغيل اللغة. يمكنك تعلم كيفية تطبيقه على لغتك المفضلة باتباع هذا البرنامج التعليمي.
يتم توفير المصادقة في هذا الإجراء في طبقة النظام الأساسي للاستضافة بواسطة Azure App Service. يجب نشر تطبيق الواجهة الأمامية والخلفية وتكوين المصادقة لتطبيق الويب هذا لاستخدامه بنجاح.
بعد إكمال هذا السيناريو، تابع إلى البرنامج التعليمي التالي لمعرفة كيفية الاتصال بخدمات Azure كمستخدم مصادق عليه. تتضمن السيناريوهات الشائعة الوصول إلى Azure Storage أو قاعدة بيانات كمستخدم لديه قدرات محددة أو الوصول إلى جداول أو ملفات معينة.
في هذا البرنامج التعليمي، سوف تتعلّم:
- تمكين المصادقة والتفويض المضمنين
- تأمين التطبيقات ضد الطلبات غير المصادقة
- استخدام معرف Microsoft Entra كموفر هوية
- الوصول إلى تطبيق بعيد نيابة عن المستخدم الذي قام بتسجيل الدخول
- مكالمات آمنة من خدمة إلى خدمة مع مصادقة الرمز المميز
- استخدام رموز الوصول المميزة من رمز الخادم
المتطلبات الأساسية
إذا لم يكن لديك حساب Azure، فأنشئ حساباً مجانياً قبل أن تبدأ.
استخدم بيئة Bash في Azure Cloud Shell. لمزيد من المعلومات، راجع بدء استخدام Azure Cloud Shell.
إذا كنت تفضل تشغيل أوامر مرجع CLI محلياً قم بتثبيت CLI Azure. إذا كنت تعمل على نظام تشغيل Windows أو macOS، ففكر في تشغيل Azure CLI في حاوية Docker. لمزيد من المعلومات، راجع كيفية تشغيل Azure CLI في حاوية Docker.
إذا كنت تستخدم تثبيت محلي، يُرجى تسجيل الدخول إلى Azure CLI مستخدمًا أمر az login. لإنهاء عملية المصادقة، اتبع الخطوات المعروضة في جهازك. للحصول على خيارات تسجيل الدخول الأخرى، راجع المصادقة على Azure باستخدام Azure CLI.
عندما يُطلب منك، قم بتثبيت ملحق Azure CLI عند الاستخدام لأول مرة. لمزيد من المعلومات حول الملحقات، راجع استخدام الملحقات وإدارتها باستخدام Azure CLI.
يُرجى تشغيل إصدار az للوصول إلى الإصدار والمكتبات التابعة التي تم تثبيتها. للتحديث لآخر إصدار، يُرجى تشغيل تحديث az.
الحصول على ملف تعريف المستخدم
تم تكوين تطبيق الواجهة الأمامية لاستخدام واجهة برمجة التطبيقات الخلفية بشكل آمن. يوفر تطبيق الواجهة الأمامية تسجيل دخول Microsoft للمستخدم، ثم يسمح للمستخدم بالحصول على ملف تعريفه المزيف من النهاية الخلفية. يستخدم هذا البرنامج التعليمي ملف تعريف مزيف لتبسيط الخطوات لإكمال السيناريو.
قبل تشغيل التعليمات البرمجية المصدر على الواجهة الأمامية، تقوم App Service بإدخال المصادق عليه accessToken من عنوان App Service x-ms-token-aad-access-token . ثم تقوم التعليمات البرمجية المصدر للواجهة الأمامية بالوصول إلى الخادم الخلفي وإرساله accessToken . يرسل خادم الواجهة الأمامية الرمز المميز ك bearerToken للوصول بأمان إلى واجهة برمجة التطبيقات الخلفية. يتحقق bearerToken الخادم الخلفي من صحة قبل تمريره إلى التعليمات البرمجية المصدر الخلفية. بعد أن تتلقى التعليمات bearerTokenالبرمجية المصدر الخلفية الخاصة بك ، يمكن استخدامها.
في البرنامج التعليمي التالي في هذه السلسلة، bearerToken يتم استبدال برمز مميز مع نطاق للوصول إلى Microsoft Graph API. تقوم واجهة برمجة تطبيقات Microsoft Graph بإرجاع معلومات ملف تعريف المستخدم.
استنساخ نموذج التطبيق
في Azure Cloud Shell، قم بتشغيل الأمر التالي لاستنساخ مستودع العينة.
git clone https://github.com/Azure-Samples/js-e2e-web-app-easy-auth-app-to-app
إنشاء التطبيقات ونشرها
أنشئ مجموعة الموارد وخطة تطبيق الويب وتطبيق الويب، ثم انشر في خطوة واحدة.
قم بالتغيير إلى
frontendدليل تطبيق الويب.cd js-e2e-web-app-easy-auth-app-to-app/frontendإنشاء تطبيق الويب الأمامي ونشره باستخدام الأمر az webapp up . يجب أن يكون اسم تطبيق الويب فريدا عالميا. استبدل
<front-end-app-name>باسم فريد.az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --os-type Windows --location "West Europe" --runtime "NODE:24LTS"قم بالتغيير إلى
backendدليل تطبيق الويب.cd ../backendنشر تطبيق الويب الخلفي إلى نفس مجموعة الموارد وخطة التطبيق. يجب أن يكون اسم تطبيق الويب فريدا عالميا. استبدل
<back-end-app-name>بسلسلة فريدة من الأحرف والأرقام.az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --os-type Windows --location "West Europe" --runtime "NODE:24LTS"
قم بالتغيير إلى
frontendدليل تطبيق الويب.cd frontendإنشاء تطبيق الويب الأمامي ونشره باستخدام الأمر az webapp up . يجب أن يكون اسم تطبيق الويب فريدا عالميا. استبدل
<front-end-app-name>بسلسلة فريدة من الأحرف والأرقام.az webapp up --resource-group myAuthResourceGroup --name <front-end-app-name> --plan myPlan --sku FREE --location "West Europe" --os-type Linux --runtime "NODE:24-lts"قم بالتغيير إلى
backendدليل تطبيق الويب.cd ../backendنشر تطبيق الويب الخلفي إلى نفس مجموعة الموارد وخطة التطبيق. يجب أن يكون اسم تطبيق الويب فريدا عالميا. استبدل
<back-end-app-name>بسلسلة فريدة من الأحرف والأرقام.az webapp up --resource-group myAuthResourceGroup --name <back-end-app-name> --plan myPlan --sku FREE --location "West Europe" --runtime "NODE:24-lts"
تكوين إعداد التطبيق
يحتاج تطبيق الواجهة الأمامية إلى معرفة عنوان URL للتطبيق الخلفي لطلبات واجهة برمجة التطبيقات. استخدم أمر Azure CLI التالي لتكوين إعداد التطبيق. يجب أن يكون https://<back-end-app-name>.azurewebsites.netعنوان URL .
az webapp config appsettings set --resource-group myAuthResourceGroup --name <front-end-app-name> --settings BACKEND_URL="https://<back-end-app-name>.azurewebsites.net"
الواجهة الأمامية تستدعي الواجهة الخلفية
استعرض للوصول إلى تطبيق الواجهة الأمامية وارجع ملف التعريف المزيف من النهاية الخلفية. يتحقق هذا الإجراء من أن الواجهة الأمامية تطلب بنجاح ملف التعريف من النهاية الخلفية، والنهاية الخلفية تعيد ملف التعريف.
افتح تطبيق الويب الأمامي في مستعرض:
https://<front-end-app-name>.azurewebsites.net.
حدد ارتباط الحصول على ملف تعريف المستخدم .
عرض ملف التعريف المزيف الذي تم إرجاعه من تطبيق الويب الخلفي.
withAuthenticationتشير قيمة false إلى أن المصادقة لم يتم إعدادها بعد.
تكوين المصادقة
في هذا القسم، قم بتمكين المصادقة والتخويل لتطبيقي الويب. يستخدم هذا البرنامج التعليمي معرف Microsoft Entra كموفر الهوية.
يمكنك أيضا تكوين تطبيق الواجهة الأمامية من أجل:
- منح تطبيق الواجهة الأمامية حق الوصول إلى التطبيق الخلفي
- تكوين خدمة التطبيقات لإرجاع رمز مميز قابل للاستخدام
- استخدام الرمز المميز في التعليمات البرمجية الخاصة بك
لمزيد من المعلومات، راجع تكوين مصادقة Microsoft Entra لتطبيق App Services.
تمكين المصادقة والتخويل للتطبيق الخلفي
في مدخل Azure، ابحث عن مجموعات المواردوحددها .
في مجموعات الموارد، ابحث عن مجموعة الموارد وحددها. في نظرة عامة، حدد التطبيق الخلفي.
في القائمة اليسرى لتطبيقك الخلفي، حدد Settings>Authentication، ثم حدد Add identity provider.
في صفحة إضافة موفر هوية ، لموفر الهوية، حدد Microsoft لتسجيل الدخول باستخدام هويات Microsoft وMicrosoft Entra.
حدد قيمة لانتهاء صلاحية سر العميل.
بالنسبة للقيم الأخرى، اقبل الإعدادات الافتراضية وحدد إضافة.
تفتح صفحة المُصادقة. انسخ معرف العميل لتطبيق Microsoft Entra إلى المفكرة. تحتاج هذه القيمة لاحقًا.
إذا توقفت هنا، فلديك تطبيق قائم بذاته تؤمنه مصادقة App Service والتخويل. توضح لك الأقسام المتبقية كيفية تأمين حل تطبيق متعدد عن طريق تدفق المستخدم المصادق عليه من الواجهة الأمامية إلى النهاية الخلفية.
تمكين المصادقة والتخويل لتطبيق الواجهة الأمامية
في مدخل Azure، ابحث عن مجموعات المواردوحددها .
في مجموعات الموارد، ابحث عن مجموعة الموارد وحددها. في نظرة عامة، حدد تطبيق الواجهة الأمامية.
في القائمة اليسرى لتطبيق الواجهة الأمامية، حدد Settings>Authentication، ثم حدد Add identity provider.
في صفحة إضافة موفر هوية ، لموفر الهوية، حدد Microsoft لتسجيل الدخول باستخدام هويات Microsoft وMicrosoft Entra.
حدد قيمة لانتهاء صلاحية سر العميل. بالنسبة للقيم الأخرى، اقبل الإعدادات الافتراضية وحدد إضافة.
تفتح صفحة المُصادقة. انسخ معرف العميل لتطبيق Microsoft Entra إلى المفكرة. تحتاج هذه القيمة لاحقًا.
منح تطبيق الواجهة الأمامية حق الوصول إلى التطبيق الخلفي
لقد قمت بتمكين المصادقة والتخويل لكلا التطبيقين. لإكمال المصادقة، تحتاج إلى القيام بثلاثة أشياء:
- عرض تطبيق الواجهة الخلفية كواجهة برمجة تطبيقات من خلال تحديد نطاق
- منح تطبيق الواجهة الأمامية حق الوصول إلى تطبيق الواجهة الخلفية
- تكوين خدمة التطبيقات لإرجاع رمز مميز قابل للاستخدام
- استخدام الرمز المميز في التعليمات البرمجية الخاصة بك
إشعار
قبل أن تتمكن من منح تطبيق الواجهة الأمامية حق الوصول إلى الواجهة الخلفية، يجب عليك عرض واجهة برمجة تطبيقات الواجهة الخلفية عن طريق تعيين عنوان URI لمعرف التطبيق وتحديد نطاق واحد على الأقل. يسمح هذا بتحديد الواجهة الخلفية ضمن "واجهات برمجة التطبيقات الخاصة بي" عند تعيين أذونات واجهة برمجة التطبيقات.
تلميح
إذا واجهت أخطاء وأعدت تكوين إعدادات المصادقة/التخويل لتطبيقك، فقد لا يتم إعادة إنشاء الرموز المميزة في مخزن الرمز المميز من الإعدادات الجديدة. للتأكد من إعادة إنشاء الرموز المميزة الخاصة بك، تحتاج إلى تسجيل الخروج وتسجيل الدخول مرة أخرى إلى تطبيقك. تتمثل إحدى الطرق في استخدام المستعرض في الوضع الخاص. أغلق المستعرض وأعد فتحه في الوضع الخاص بعد تغيير الإعدادات في تطبيقاتك.
في هذا القسم، يمكنك منح التطبيق الأمامي حق الوصول إلى التطبيق الخلفي نيابة عن المستخدم. من الناحية الفنية، يمكنك منح تطبيق AD للواجهة الأمامية أذونات للوصول إلى تطبيق AD للواجهة الخلفية نيابة عن المستخدم.
في صفحة المصادقة لتطبيق الواجهة الأمامية، ضمن موفر الهوية، حدد اسم تطبيق الواجهة الأمامية. تم إنشاء تسجيل التطبيق هذا تلقائياً لك.
حدد إدارة>أذونات واجهة برمجة التطبيقات في القائمة اليمنى.
حدد إضافة إذن، ثم حدد My APIs><back-end-app-name>.
في صفحة طلب أذونات واجهة برمجة التطبيقات للتطبيق الخلفي، حدد الأذونات المفوضةuser_impersonation، ثم حدد إضافة أذونات.
تكوين خدمة التطبيقات لإرجاع رمز مميز للوصول قابل للاستخدام
يحتوي تطبيق الواجهة الأمامية الآن على الأذونات المطلوبة للوصول إلى التطبيق الخلفي كمستخدم قام بتسجيل الدخول. في هذا القسم، قم بتكوين مصادقة خدمة التطبيقات والتخويل لمنحك رمز وصول قابل للاستخدام للوصول إلى النهاية الخلفية. لهذه الخطوة، تحتاج إلى معرف العميل الخلفي، الذي نسخته من تمكين المصادقة والتخويل للتطبيق الخلفي.
في Cloud Shell، قم بتشغيل الأوامر التالية على تطبيق الواجهة الأمامية لإضافة المعلمة scope إلى إعداد identityProviders.azureActiveDirectory.login.loginParametersالمصادقة . استبدل <front-end-app-name> و <back-end-client-id>.
az extension add --name authV2
authSettings=$(az webapp auth show -g myAuthResourceGroup -n <front-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.login += {"loginParameters":["scope=openid offline_access api://<back-end-client-id>/user_impersonation"]}')
az webapp auth set --resource-group myAuthResourceGroup --name <front-end-app-name> --body "$authSettings"
تضيف الأوامر خاصية loginParameters مع نطاقات مخصصة أخرى. وفيما يلي شرح للنطاق المطلوب:
-
openidمطلوب من قبل App Service بشكل افتراضي بالفعل. لمزيد من المعلومات، راجع OpenID Connect Scopes. - يتم تضمين offline_access هنا للراحة، في حالة رغبتك في تحديث الرموز المميزة.
-
api://<back-end-client-id>/user_impersonationهي واجهة برمجة تطبيقات مكشوفة في تسجيل التطبيق الخلفي. إنه النطاق الذي يمنحك JWT الذي يتضمن التطبيق الخلفي كجمهور رمز مميز.
تلميح
- لعرض
api://<back-end-client-id>/user_impersonationالنطاق في مدخل Microsoft Azure، انتقل إلى صفحة المصادقة للتطبيق الخلفي، وحدد الارتباط ضمن موفر الهوية، ثم حدد كشف واجهة برمجة التطبيقات في القائمة اليمنى. - لتكوين النطاقات المطلوبة باستخدام واجهة ويب بدلا من ذلك، راجع تحديث رموز المصادقة المميزة.
- تتطلب بعض النطاقات موافقة المسؤول أو المستخدم. يؤدي هذا المطلب إلى ظهور صفحة طلب الموافقة عندما يقوم مستخدم بتسجيل الدخول إلى تطبيق الواجهة الأمامية في المستعرض. لتجنب صفحة الموافقة هذه، أضف تسجيل تطبيق الواجهة الأمامية كتطبيق عميل معتمد في صفحة كشف واجهة برمجة التطبيقات . حدد Add a client application وقم بتوفير معرف العميل لتسجيل تطبيق الواجهة الأمامية.
تم تكوين تطبيقاتك الآن. الواجهة الأمامية جاهزة الآن للوصول إلى النهاية الخلفية برمز وصول مناسب.
للحصول على معلومات حول كيفية تكوين رمز الوصول للموفرين الآخرين، راجع تحديث الرموز المميزة لموفر الهوية.
تكوين خدمة التطبيقات الخلفية لقبول رمز مميز فقط من خدمة التطبيقات الأمامية
يجب عليك أيضا تكوين خدمة التطبيقات الخلفية لقبول رمز مميز فقط من خدمة التطبيقات الأمامية. يؤدي عدم القيام بهذا التكوين إلى خطأ 403: ممنوع عند تمرير الرمز المميز من الواجهة الأمامية إلى النهاية الخلفية.
يمكنك تنفيذ هذا الأسلوب باستخدام نفس عملية Azure CLI التي استخدمتها في الخطوة السابقة.
احصل على
appIdخدمة التطبيقات الأمامية. يمكنك الحصول على هذه القيمة في صفحة المصادقة لخدمة التطبيقات الأمامية.قم بتشغيل Azure CLI التالي، واستبدال و
<back-end-app-name><front-end-app-id>.
authSettings=$(az webapp auth show -g myAuthResourceGroup -n <back-end-app-name>)
authSettings=$(echo "$authSettings" | jq '.properties' | jq '.identityProviders.azureActiveDirectory.validation.defaultAuthorizationPolicy.allowedApplications += ["<front-end-app-id>"]')
az webapp auth set --resource-group myAuthResourceGroup --name <back-end-app-name> --body "$authSettings"
الواجهة الأمامية تستدعي الواجهة الخلفية المصادق عليها
يحتاج تطبيق الواجهة الأمامية إلى تمرير مصادقة المستخدم مع النطاق الصحيح user_impersonation إلى النهاية الخلفية. تستعرض الخطوات التالية التعليمات البرمجية المتوفرة في العينة لهذه الوظيفة.
عرض التعليمات البرمجية المصدر لتطبيق الواجهة الأمامية:
استخدم عنوان App Service الذي تم إدخاله
x-ms-token-aad-access-tokenفي الواجهة الأمامية للحصول على accessToken للمستخدم برمجيا.// ./src/server.js const accessToken = req.headers['x-ms-token-aad-access-token'];استخدم accessToken في
Authenticationالعنوان كقيمةbearerToken.// ./src/remoteProfile.js // Get profile from backend const response = await fetch(remoteUrl, { cache: "no-store", // no caching -- for demo purposes only method: 'GET', headers: { 'Authorization': `Bearer ${accessToken}` } }); if (response.ok) { const { profile } = await response.json(); console.log(`profile: ${profile}`); } else { // error handling }يقوم هذا البرنامج التعليمي بإرجاع ملف تعريف مزيف لتبسيط السيناريو. يوضح البرنامج التعليمي التالي في هذه السلسلة كيفية استبدال النهاية الخلفية
bearerTokenبرمز مميز جديد مع نطاق خدمة Azure المتلقية للمعلومات، مثل Microsoft Graph.
ترجع الواجهة الخلفية ملف التعريف إلى الواجهة الأمامية
إذا لم يكن الطلب من الواجهة الأمامية معتمدا، ترفض خدمة التطبيقات الخلفية الطلب برمز خطأ HTTP 401 قبل أن يصل الطلب إلى رمز التطبيق الخاص بك. عند الوصول إلى التعليمات البرمجية الخلفية، لأنها تتضمن رمزا مميزا معتمدا، قم باستخراج bearerToken للحصول على accessToken.
عرض التعليمات البرمجية المصدر للتطبيق الخلفي:
// ./src/server.js
const bearerToken = req.headers['Authorization'] || req.headers['authorization'];
if (bearerToken) {
const accessToken = bearerToken.split(' ')[1];
console.log(`backend server.js accessToken: ${!!accessToken ? 'found' : 'not found'}`);
// TODO: get profile from Graph API
// provided in next article in this series
// return await getProfileFromMicrosoftGraph(accessToken)
// return fake profile for this tutorial
return {
"displayName": "John Doe",
"withAuthentication": !!accessToken ? true : false
}
}
الاستعراض للوصول إلى التطبيقات
استخدم موقع الواجهة الأمامية على ويب في مستعرض. عنوان URL هو
https://<front-end-app-name>.azurewebsites.net/.يطلب المستعرض المصادقة الخاصة بك إلى تطبيق الويب. أكمل المصادقة.
بعد اكتمال المصادقة، يقوم تطبيق الواجهة الأمامية بإرجاع الصفحة الرئيسية للتطبيق.
حدد الحصول على ملف تعريف المستخدم. يمرر هذا الإجراء المصادقة الخاصة بك في الرمز المميز للحامل إلى النهاية الخلفية.
تستجيب النهاية الخلفية باسم ملف التعريف
John Doeالمشفرة: .
withAuthenticationتشير قيمة true إلى أنه تم إعداد المصادقة الآن.
تنظيف الموارد
في الخطوات السابقة، أنشأت موارد Azure في إحدى مجموعات الموارد.
احذف مجموعة الموارد عن طريق تشغيل الأمر التالي في Cloud Shell. ربما يستغرق الأمر بضع دقائق للتشغيل.
az group delete --name myAuthResourceGroupاستخدم معرف العميل لتطبيقات المصادقة، الذي عثرت عليه مسبقا وقمت بتدوينه في
Enable authentication and authorizationأقسام تطبيقات الواجهة الخلفية والواجهة الأمامية.احذف تسجيلات التطبيقات لكل من تطبيقات الواجهة الأمامية والخلفية.
# delete app - do this for both frontend and backend client ids az ad app delete --id <client-id>
الأسئلة الشائعة
كيف أعمل اختبار هذه المصادقة على جهاز التطوير المحلي الخاص بي؟
يتم توفير المصادقة في هذا الإجراء في طبقة النظام الأساسي للاستضافة بواسطة Azure App Service. لا يوجد محاكي مكافئ. يجب نشر تطبيق الواجهة الأمامية والخلفية وتكوين المصادقة لكل منها لاستخدام المصادقة.
لا يعرض التطبيق ملف تعريف مزيف، كيف يمكنني تصحيحه؟
لكل /debug من التطبيقين الأمامي والخلفي مسارات للمساعدة في تصحيح المصادقة عندما لا يرجع هذا التطبيق ملف التعريف المزيف . يوفر مسار تتبع أخطاء الواجهة الأمامية الأجزاء الهامة للتحقق من صحتها:
متغيرات البيئة:
-
BACKEND_URLتم تكوين بشكل صحيح كhttps://<back-end-app-name>.azurewebsites.net. لا تقم بتضمين الشرطة المائلة اللاحقة للأمام أو المسار.
-
رؤوس HTTP:
-
x-ms-token-*يتم حقن الرؤوس.
-
يتم عرض اسم ملف تعريف Microsoft Graph للمستخدم الذي قام بتسجيل الدخول.
يحتوي
user_impersonationنطاق تطبيق الواجهة الأمامية للرمز المميز على . إذا لم يتضمن نطاقك هذه القيمة، فقد تكون مشكلة في التوقيت. تحقق من معلمات تطبيقloginالواجهة الأمامية في موارد Azure. انتظر بضع دقائق للنسخ المتماثل للمصادقة.
هل تم نشر التعليمات البرمجية المصدر للتطبيق بشكل صحيح لكل تطبيق ويب؟
في مدخل Microsoft Azure لتطبيق الويب، حدد أدوات التطوير الأدوات>المتقدمة، ثم حدد Go. يفتح هذا الإجراء علامة تبويب أو نافذة مستعرض جديدة.
في علامة تبويب المستعرض الجديد، حدد Browse Directory>Site wwwroot.
تحقق مما يلي في الدليل:
- package.json
- node_modules.tar.gz
- /src/index.js
تحقق من أن الخاصية package.json
nameهي نفس اسم الويب، إماfrontendأوbackend.إذا قمت بتغيير التعليمات البرمجية المصدر، وتحتاج إلى إعادة النشر، فاستخدم الأمر az webapp up من الدليل الذي يحتوي على ملف package.json لهذا التطبيق.
هل بدأ التطبيق بشكل صحيح؟
يجب أن يرجع كلا تطبيقي الويب شيئا عند طلب الصفحة الرئيسية. إذا تعذر عليك الوصول إلى /debug تطبيق ويب، فلن يبدأ التطبيق بشكل صحيح. راجع سجلات الخطأ لتطبيق الويب هذا.
- في مدخل Microsoft Azure لتطبيق الويب، حدد أدوات التطوير الأدوات>المتقدمة، ثم حدد Go. يفتح هذا الإجراء علامة تبويب أو نافذة مستعرض جديدة.
- في علامة تبويب المستعرض الجديدة، حدد Browse Directory>Deployment Logs.
- راجع كل سجل للعثور على أي مشكلات تم الإبلاغ عنها.
هل يمكن لتطبيق الواجهة الأمامية التحدث إلى التطبيق الخلفي؟
نظرا لأن تطبيق الواجهة الأمامية يستدعي التطبيق الخلفي من التعليمات البرمجية المصدر للخادم، فإن هذا السلوك ليس شيئا يمكنك رؤيته في حركة مرور شبكة المستعرض. استخدم القائمة التالية لتحديد نجاح طلب ملف التعريف الخلفي:
يقوم تطبيق الويب الخلفي بإرجاع أي أخطاء إلى تطبيق الواجهة الأمامية إذا تم الوصول إليه. إذا لم يتم الوصول إليه، يقوم تطبيق الواجهة الأمامية بالإبلاغ عن رمز الحالة والرسالة.
- 401: لم يمرر المستخدم المصادقة بشكل صحيح. يمكن أن تشير هذه الرسالة إلى عدم تعيين النطاق بشكل صحيح.
- 404: عنوان URL للخادم لا يتطابق مع المسار الذي يحتوي عليه الخادم
استخدم سجلات دفق التطبيق الخلفي لمشاهدة أثناء تقديم طلب الواجهة الأمامية لملف تعريف المستخدم. هناك معلومات تتبع الأخطاء في التعليمات البرمجية المصدر باستخدام
console.log، مما يساعد على تحديد مكان حدوث الفشل.
ماذا يحدث عند انتهاء صلاحية الرمز المميز للواجهة الأمامية؟
تنتهي صلاحية رمز الوصول الخاص بك بعد مرور بعض الوقت. للحصول على معلومات حول كيفية تحديث رموز الوصول الخاصة بك دون مطالبة المستخدمين بإعادة المصادقة مع التطبيق الخاص بك، راجع تحديث الرموز المميزة لموفر الهوية.
إذا كان لدي تطبيق يستند إلى المستعرض على تطبيق الواجهة الأمامية، هل يمكنه التحدث إلى الواجهة الخلفية مباشرة؟
يتطلب هذا الأسلوب رمز الخادم لتمرير الرمز المميز للوصول إلى رمز JavaScript الذي يعمل في متصفح العميل. نظرا لعدم وجود طريقة لحماية الرمز المميز للوصول في المتصفح، لا نوصي بهذا النهج. حاليا، نوصي بنمط الواجهة الخلفية للواجهة الأمامية.
إذا تم تطبيقه على المثال في هذا البرنامج التعليمي، فإن التعليمة البرمجية للمستعرض على تطبيق الواجهة الأمامية ستقوم بإجراء استدعاءات API في جلسة مصادق عليها إلى رمز الخادم الخاص به كوسيط. ثم تقوم التعليمات البرمجية للخادم على تطبيق الواجهة الأمامية بإجراء استدعاءات واجهة برمجة التطبيقات إلى التطبيق الخلفي باستخدام x-ms-token-aad-access-token قيمة العنوان كرمز مميز للحامل. جميع المكالمات من التعليمات البرمجية للمستعرض إلى رمز الخادم محمية بواسطة جلسة العمل المصادق عليها.
الخطوة التالية
تقدم إلى البرنامج التعليمي التالي لمعرفة كيفية استخدام هوية هذا المستخدم للوصول إلى خدمة Azure.