مرحبًا!
نقوم بإرسال دعوة من Discourse إلى مستخدمينا بمجرد إنشاء حساب لهم في تطبيقنا. لدينا بالفعل اسمهم والحقول المخصصة التي نحتاجها لمجتمعنا، لكن المستخدم مطالب بإدخالها مرة أخرى على Discourse.
هل توجد طريقة لإكمال هذه الحقول كجزء من ملفهم الشخصي؟
شكرًا!
أعتقد أن الأفضل هو أن يكون تطبيقك هو خادم SSO. إذا لم ترغب في ذلك، فيمكن لتطبيقك إنشاء المستخدم عبر واجهة برمجة التطبيقات (API) وتضمين تلك الإعدادات. يمكنك معرفة كيفية القيام بذلك من خلال كيفية عكس هندسة واجهة برمجة تطبيقات Discourse.
لا نرغب في إنشاء مستخدمين عبر واجهة برمجة التطبيقات (API) لأننا نريد من المستخدم إنشاء كلمة مرور واختيار اسم مستخدمه. كنت أبحث في إنشاء مستخدم مؤقت بجميع البيانات، لكن يبدو أن هذا غير ممكن عبر واجهة برمجة التطبيقات.
الخيار الآخر الذي يمكنني التفكير فيه هو توسيع نطاق الدعوات للسماح بإضافة حقول مخصصة ومعلومات الملف الشخصي.
ربما إضافة (plugin) تقوم بسحب الحقول من تطبيقك عبر استدعاء ويب هوك (webhook) أو واجهة برمجة تطبيقات (API)؟ يمكن للإضافة أن تقوم بشيء مثل get yoursite/user/<email_address> وملء حقول المستخدم عند تحديث سجل المستخدم. شيء من هذا القبيل. لا يزال تسجيل الدخول الموحد (SSO) يبدو الحل الأفضل.
نعم، يُرجى الاطلاع على Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso). هذا هو حالة الاستخدام المثالية للدخول الموحد (Single Sign On).
ومع ذلك، باستخدام الدخول الموحد (SSO)، لن تحتاج إلى إرسال دعوات إليهم. فبمجرد زيارتهم لمثيل Discourse الخاص بك، سيتم تسجيل دخولهم تلقائيًا إذا كانوا مسجلين بالفعل في تطبيقك. وإذا لم يكونوا مسجلين في تطبيقك، فسيقوم Discourse بإعادة توجيههم إلى تطبيقك لتسجيل الدخول، ثم سيتم إعادة توجيههم تلقائيًا مرة أخرى إلى Discourse.
المشكلة هي أننا نستخدم ديسكورد كمزود لتسجيل الدخول الموحد (SSO)، وقد عمل هذا بشكل جيد معنا، ولكن نعم، أوافق على أن الأمر سيكون أسهل لو كان ديسكورد يستهلك مزود تسجيل دخول موحد.
@blake ما زلت أفكر في كيفية القيام بذلك بما أننا نستخدم Discourse كمزود SSO. لا أريد الانتقال إلى شيء آخر في الوقت الحالي لأن ذلك سيتطلب الكثير من العمل. هل لديك أفكار أخرى؟ ليس هناك مشكلة إذا اضطررنا لكتابة كود مخصص، لكننا نرغب في إجراء أقل عدد ممكن من التغييرات على كيفية إعداد الأمور لدينا.
شكرًا!
أنا فقط مرتبك بسبب إعدادك وهذه الجملتين، لأنه في هذه الحالة لا تملك تسجيل دخول واحدًا (Single Sign-On) بل تسجيل دخول مزدوجًا (Double Sign-On)؟
إذا كان Discourse هو مزود تسجيل الدخول الموحد لديك، فيجب أن يتم توجيه المستخدمين الجدد في تطبيقك أولاً إلى Discourse لإنشاء حساب، ثم إعادتهم إلى تطبيقك بعد المصادقة. وبهذه الطريقة تكون جميع المعلومات في مكان واحد.
بناءً على فهمي الحالي، سأقوم بتحويل تطبيقك إلى مزود لتسجيل الدخول الموحد (SSO) ليتناوله Discourse. أو سأوجه مستخدمين تطبيقك للتسجيل أولاً في Discourse ثم إعادة توجيههم إلى تطبيقك، لأن هذا على ما يبدو ليس هو الإعداد الحالي؟
وإلا، إذا كنت ترغب في إعداد تسجيل دخول مزدوج (Dual Sign-On)، فبمجرد تسجيل المستخدم في تطبيقك، قم تلقائيًا عبر الـ API بإنشاء حساب له في Discourse بكلمة مرور عشوائية لا تمنحها للمستخدم أبدًا، وأملأ تلقائيًا معلومات ملفه الشخصي التي أدخلها في تطبيقك. ثم أرسله إلى صفحة إعادة تعيين كلمة المرور في Discourse لحسابه الجديد بدلاً من إرسال دعوة له.
نقوم بالتسجيل عبر تطبيقنا، لكن تطبيقنا لا يحتوي على إدارة جلسات. نحن فقط نخصم الرسوم من المستخدم ونخزن معلوماته في قاعدة بياناتنا.
سنحتاج إلى إلزام المستخدم بإنشاء حساب أولاً، وهذه هي الخطوة التي نود استبعادها، لأننا نرغب في جعل العملية أسهل ما يمكن.
هذا هو الجهد الذي لا نرغب في الدخول فيه، لأن إضافة إدارة الجلسات، واستعادة كلمة المرور، والمصادقة الثنائية (2FA)، وجميع الميزات التي يوفرها Discourse سيتطلب الكثير من العمل.
هذا ليس ما نريده.
هذا ما فعلته في البداية، لكننا نضطر إلى تعيين اسم مستخدم عشوائي، وهذا ليس ما نريده. بينما سيعمل هذا الحل، نرغب في أن يتمكن المستخدم من تخصيص حسابه قبل البدء في استخدام المجتمع.
لكن نعم، أعتقد أن الإجابة لا تزال هي استخدام مزوّد SSO خارجي. سأسير في هذا المسار وأتوقف عن التفكير في كيفية استغلال Discourse وجعله يعمل بالطريقة التي نريدها.
شكرًا لك على المساعدة @blake!
أم تفضل التخلص من تطبيقك والسماح لـ Discourse Subscriptions بالتعامل مع الأموال؟