أنشئ مخططًا تسلسليًا بلغة UML لتدفق مصادقة REST API يضم العميل، وبوابة API، وخدمة المصادقة، وقاعدة البيانات
حول الإطار
يضم مثال التسلسل خمسة أطراف: المستخدم، والمتصفح، والواجهة الخلفية لـ API، وموفّر OAuth، وقاعدة البيانات. تبدأ الرسائل الاثنتا عشرة بالنقر على «تسجيل الدخول باستخدام Google»، ثم تتابع التفويض، والموافقة، واستدعاء رمز التفويض العكسي، وتبادل الرموز، وإنشاء سجل المستخدم أو تحديثه، وضبط ملف ارتباط الجلسة، وإعادة التوجيه إلى لوحة التحكم.
يعيد الموفّر في هذا المثال رمز وصول ورمز تعريف معًا. يعرض المخطط مسار النجاح فقط، ولا يوضّح التحقق من الرموز، أو فحوصات مطابقة الطلبات، أو PKCE، أو رفض الموافقة، أو الرموز منتهية الصلاحية، أو أعطال قاعدة البيانات. وقد وُسِم الاستدعاء العكسي تحديدًا بالمسار POST /auth/callback؛ وهذه خطوة نموذجية في التطبيق ينبغي مواءمتها مع تنفيذك الخاص.
استخدم التسلسل لتوضيح الجهة التي تبدأ كل طلب والموضع الذي يسلّم فيه المتصفح المهمة إلى الخادم. وسّعه بخطوات التحقق والنتائج البديلة قبل اعتماده كمواصفة تصميم. واحرص على توضيح تفاصيل البروتوكول وسلوك الجلسة الخاص بالتطبيق.
ما المدرج
مخطط تسلسلي UML - مصادقة API
✦ Free preview · Sign in to use
الأسئلة الشائعة
لا. تنتمي الرسائل الاثنتا عشرة جميعها إلى مسار النجاح. اطلب فروعًا بديلة للتعامل مع رفض الموافقة، والرموز غير الصالحة أو منتهية الصلاحية، وفشل كتابة سجل المستخدم.
ينشئ نموذج الواجهة الخلفية سجلًا للمستخدم أو يحدّثه، ويتلقى كائن المستخدم، ويضبط ملف ارتباط للجلسة. لكنه لا يوضّح التحقق من الرموز أو تفاصيل تخزين الجلسة.
ينتمي هذا الوسم إلى المثال. طابِق رسائل الاستدعاء العكسي مع إعدادات موفّر الخدمة ومسارات الواجهة الخلفية لديك، مع التمييز بين إعادة التوجيه من الموفّر وأي طلب لاحق من المتصفح إلى الواجهة الخلفية.
مجاني للبدء. لا حاجة لبطاقة ائتمان.