التطبيق لا يمتلك إدارة مستخدمين خاصة به، وأود استخدام Discourse لذلك (لأنه لا توجد لدينا أشياء أخرى خاصة بالمستخدم تحتاج إلى إدارة مستخدمين خاصة بها).
لكنني أود عرض المستخدم المسجل دخوله حاليًا في Discourse في التطبيق، بالإضافة إلى عرض أداة مصغرة للمواضيع غير المقروءة (وهي خاصة بالمستخدم)، على سبيل المثال، لذا أحتاج إلى تحميل البيانات عبر واجهة برمجة التطبيقات (API) من Discourse.
الأشياء التي جربتها:
استخدام مسار Discourse SSO، والذي يعيد التوجيه بعد ذلك إلى تطبيقي. هذا جيد، أحصل على عنوان البريد الإلكتروني للمستخدم الحالي، ومعرف خارجي، وما إلى ذلك - ولكن لا شيء يمكنني استخدامه للطلب (رمز مميز / مفتاح).
اللعب بإعدادات ملفات تعريف الارتباط (cookies) لاستخدام ملف تعريف الارتباط الخاص بـ Discourse لإجراء الطلب (لم ينجح).
قم بإنشاء مفتاح API بالنطاقات التي تحتاجها مع وصول “جميع المستخدمين”.
من الواضح أنه لا يمكنك تمرير هذا المفتاح إلى تطبيق الويب من جانب العميل دون تعريض الموقع للخطر، لذلك ستحتاج إلى وكالة طلبات من تطبيق الويب عبر الواجهة الخلفية لهذا التطبيق إلى مثيل Discourse الخاص بك. (وستحتاج إلى التحقق من أن اسم المستخدم شرعي من الواجهة الخلفية - لم ألقِ نظرة على DiscourseConnect ولكن يُفترض أن هناك طريقة للقيام بذلك.)
إرسال المستخدم عبر SSO، يقوم الـ Middleware بإنشاء مستخدم بسيط بالاسم والبريد الإلكتروني ومصفوفة رموز، وينشئ رمزًا، ويعيده إلى SPA.
يقوم الـ Middleware بتفويض الطلبات إلى discourse بمفتاح API لجميع المستخدمين والتحقق من صحة “رمز الجلسة” (لمعرفة أي مستخدم هو) وبعض السحر الأمني الآخر.
للسماح للمستخدم بالبقاء مسجلاً للدخول، سأستخدم ملف تعريف ارتباط / تخزين محلي وسأقوم بمزامنة تسجيل الخروج عبر خيار تسجيل الخروج المباشر لـ discourse.
إنه يعمل، لكنني ما زلت أعتقد أنه يجب أن يكون هناك خيار أفضل من التعامل مع مفتاح API إداري بالاشتراك مع اسم مستخدم. إنه ينكسر إذا قام أحد المسؤولين بتغيير اسم مستخدم شخص ما… أود معرفة معرف تجزئة أو شيء من هذا القبيل… ولكن لا شيء يمكنني تغييره، لذلك سأتعايش معه
