تم الآن تجميع هذه الإضافة مع Discourse core كجزء من Bundling more popular plugins with Discourse core. إذا كنت تستضيف بنفسك وتستخدم الإضافة، فأنت بحاجة إلى إزالتها من app.yml الخاص بك قبل الترقية التالية.
3 إعجابات
نعم لقد فعلت ذلك لأحد العملاء.
نود أن نكون قادرين على مزامنة بعض المجموعات في Discourse مع مجموعات OIDC التي لدينا. وجدنا أن هناك طلب سحب (PR) قدم هذه الوظيفة، ولكنه لم يتم أخذه في الاعتبار بشكل أكبر:
هل سيكون من الممكن إدراج هذا ضمن وظائف Discourse؟
إعجابَين (2)
هل سيتم إزالة المستخدمين تلقائيًا بمجرد عدم كونهم أعضاء في المجموعة المعنية؟
نعم، سيفعلون 
حسناً، هذا لا يتطابق مع اختباراتي في الواقع.
مرحبًا بالجميع، أستخدم مكون OpenID Connect وأحاول تمرير معاملات مخصصة في طلب /authorize عبر openid connect authorize parameters، لكن يبدو أن ذلك لا يعمل بشكل موثوق.
هل هذا مدعوم رسميًا؟ وإذا لم يكن كذلك، فما هي الطريقة الموصى بها لإرسال سياق مخصص إلى مزود الهوية (IdP)؟
شكرًا!
@david
مرحبًا،
يعمل المكوّن الإضافي بشكل جيد لسنوات، لكنني واجهت مستخدم SSO واحدًا فقط لديه اسم مستخدم ينتهي بعلامة سفلية، مثل اسم مستخدم غير مسموح به.
لا يمكن لهذا المستخدم تسجيل الدخول إلى Discourse. أعتقد أن OIDC يحاول بعد ذلك إنشاء حساب باسم مستخدم بدون علامة سفلية فقط. وهذا مقبول، ولكن إذا كان هذا الحساب موجودًا بالفعل (اسم المستخدم foo موجود، ولا يمكن لـ foo_ تسجيل الدخول بسبب خطأ “الحساب موجود بالفعل”)، يبدو أن هناك محاولة انتحال شخصية في جزء ما:
يتلقى اسم المستخدم foo بريدًا إلكترونيًا يفيد بأنه حاول إنشاء حساب أو حاول تغيير البريد الإلكتروني لحساب، لكن هذا البريد الإلكتروني كان محجوزًا بالفعل.
يحدث هذا أثناء أول تسجيل دخول، أي إنشاء الحساب عبر SSO، لـ foo_. إذن يحاول foo_ إنشاء حساب باسم foo لكنه لا يستطيع ذلك لأن الاسم محجوز بالفعل. لكن لماذا يتلقى foo الأصلي إشعارًا بالبريد الإلكتروني لذلك؟
لقد حاولت للتو إنشاء حساب في ، أو حاولت تغيير البريد الإلكتروني لحساب إلى <بريد foo الإلكتروني>
هل هناك حل لمشكلة وجود و _ في OIDC، مثل تكوين الطريقة التي يتعامل بها Discourse مع أسماء المستخدمين غير الصالحة أثناء المصادقة؟
مرحبًا،
شكرًا على آخر التعديلات على هذه الإضافة، ولكن كيف يمكنني مزامنة المشرفين عبر OIDC؟
شكرًا