عند استخدام نقطة النهاية /admin/users/sync_sso لمزامنة بيانات SSO، لا يمكن إزالة اسم شخص من الحساب، حتى لو لم يكن ذلك مطلوبًا. وبعبارة أخرى، لا يمكن تغيير اسم الحساب من شيء إلى لا شيء. يحدث هذا مع full_name_required = false (و sso_overrides_name = true).
أعتقد أن المشكلة تكمن هنا:
لكنني أخشى أن معرفتي بـ Ruby/Discourse ليست كافية لتقديم طلب سحب (PR).
يبدو هذا لي كطلب ميزة (#feature request). في الوقت الحالي، يمكنك استخدام واجهة برمجة التطبيقات (API) الخاصة بالمسؤول لمسح الأسماء في حالات مثل هذه. انظر:
عذراً، لكنني لا أوافق. لا أرى كيف يمكن اعتبار هذا طلب ميزة بدلاً من كونه عيباً.
أفهم وجود نقاط نهاية API أخرى يمكن استخدامها. لكن الهدف الرئيسي من /admin/users/sync_sso هو بالضبط الحفاظ على هذا النوع من البيانات متزامناً. إنه يسمح بالفعل بتعيين حقل اسم الحساب — وهذا يعمل. لكنه يفترض أن الاسم مطلوب دائماً ولا يسمح بتعيينه فارغاً. وبالتالي لا يمكن استخدامه للحفاظ على تزامن البيانات.
يبدو أن الكود أدناه يجعله يعمل كما هو متوقع في بيئة الاختبار الخاصة بي، لكن مرة أخرى، لا أشعر بالثقة الكافية لتقديم طلب سحب (PR) في هذه المرحلة. لا تتردد في استخدامه/تعديله، إلخ.
- if SiteSetting.sso_overrides_name && user.name != name && name.present?
- user.name = name || User.suggest_name(username.blank? ? email : username)
+ if SiteSetting.sso_overrides_name && user.name != name
+ if SiteSetting.full_name_required && name.present?
+ user.name = name || User.suggest_name(username.blank? ? email : username)
+ else
+ user.name = name
+ end
هذا طلب ميزة، والمعاني غامضة. قد يعني غياب الاسم أحد الأمرين:
أنت تطلب تغييرًا في البروتوكول هنا. أنا أميل عادةً إلى الوضوح حتى لا يكون لدينا واجهة برمجة تطبيقات مربكة.
أرى وجهة نظرك الآن.
مرة أخرى، لا أعرف التفاصيل الداخلية (أو لغة Ruby) بشكل كافٍ… لكن هل لا توجد طريقة لمعرفة ما إذا تم تقديم حقل name في هذا الطلب؟ إذا لم يكن موجودًا على الإطلاق، فلا تلمس حقل الاسم في الحساب. وإذا تم تقديم حقل الاسم، قم بتعيينه (إذا كان فارغًا، فامسحه). ألا يحترم هذا البروتوكول/السلوك الذي يتم فيه مزامنة الحقول المقدمة فقط؟
أعتذر إذا كان هذا غير منطقي — فأنا فقط أحاول فهم ما أستوعبه.
المشكلة هي أن دلالات البروتوكول الحالية للمعلمة “name”، عندما تكون موجودة ومُعيَّنة إلى قيمة فارغة، تُعتبر نفس الشيء مثل عدم وجود معلمة “name” على الإطلاق. ببساطة، لا يتم تعديلها.
أي تغيير هنا يُعدّ تغييرًا في دلالات البروتوكول. يمكننا نظريًا تعديل السلوك بحيث تصبح name= تعني أن القيمة تُفرغ، وغياب name يعني “لا تُعدّل القيمة”، لكن الناس يعتمدون بالفعل على السلوك القديم، لذا يُعدّ هذا تغييرًا تقنيًا كاسرًا.
هل يمكنك شرح سبب إزالة الأسماء؟
نحن لا نقوم بإزالة أسماء جميع المستخدمين — بل يقوم المستخدمون بتحديث بياناتهم بأنفسهم عند تحديث حساباتهم على موقعنا (موفر SSO). نعتمد على /admin/users/sync_sso لمزامنة البيانات (اسم المستخدم، الاسم، الصورة الرمزية، إلخ) في حساباتهم على Discourse. الاسم حقل اختياري ويمكن تركه فارغًا/خاليًا.
لقد أدركت للتو أن المشكلة لا تقتصر على الاسم فحسب، بل تشمل أيضًا تحديث السيرة الذاتية والصورة الرمزية وما إلى ذلك: لا يمكن مزامنة سجلات SSO هذه عبر /admin/users/sync_sso إذا كان لا بد من تحديثها لتكون فارغة/خالية، بغض النظر عما إذا كانت حقولًا إلزامية أم لا.
أفهم النقطة القائلة بأن بعض الأشخاص قد يعتمدون على السلوك الحالي (على الرغم من أن أحدًا لم يبلغ عن هذه المشكلة من قبل؟)، ولكن إذا كان هذا هو البروتوكول، فيبدو أن له قيودًا كبيرة فيما يتعلق بغرضه المتمثل في مزامنة سجلات SSO.
أنا أيضًا أتأثر بهذه المشكلة، حيث لا يستطيع المستخدمون الأفراد إزالة معلوماتهم الشخصية (مثل الاسم، والصور الرمزية، والسيرة الذاتية، والحقول المخصصة، وما إلى ذلك) من Discourse، وهو ما له تبعات كما تتخيل.
أتفق على عدم تغيير الدلالات الحالية لكيفية عمل النظام، ولكن هل لا يمكنكم السماح لنا بتعيين هذه السمات كـ false في حمولة SSO أو ما شابه ذلك لتوضيح رغبتنا في إزالتها؟
في السابق، كنا نتجاوز هذا القيد الخاص بتسجيل الدخول الموحد (SSO) عن طريق دمج استدعاء إلى نقطة النهاية /admin/users/sync_sso مع استدعاء آخر إلى نقطة النهاية /u/{username} لمجرد مسح الاسم (إذا كانت القيمة الجديدة للاسم فارغة).
ومع ذلك، يبدو أن هذا توقف عن العمل أيضًا في وقت ما في إصدار حديث، ربما لأنه يتحقق مما إذا كان sso_overrides_name = true قبل تحديث الاسم.
لذلك، كما هو الحال، عند استخدام تسجيل الدخول الموحد (SSO) و sso_overrides_name = true، يبدو الآن أنه من المستحيل على موفر تسجيل الدخول الموحد (SSO) مسح حقل الاسم في Discourse عبر واجهة برمجة التطبيقات (API).
هل يمكنك رؤية أي حل بديل لهذا، @sam؟
أعتقد أن هناك حاجة لمعامل إضافي لمسار sync_sso الخاص بنا؟ شيء مثل &clear_name لست متأكدًا. يبدو هذا حالة هامشية جدًا. ما هي حالة الاستخدام للأسماء الفارغة؟ ربما قم بتعيينها إلى اسم المستخدم إذا لم يكن لديك أي شيء ويمكن لواجهة المستخدم قمع التكرار.
من المحير بالنسبة لي أنك تعتبر هذه حالة هامشية، لذا أفترض أنه يجب أن تكون معتادًا على الحالات التي يكون فيها الاسم هو الحقل المطلوب.
لدينا العكس: اسم المستخدم هو ما يجب أن يمتلكه الجميع، والاسم هو حقل اختياري (نستخدم prioritize_username_in_ux = true و full name required = false). فكر في حسابات تويتر، حيث يجب أن يمتلك الجميع اسم مستخدم/معرف، ويمكنهم اختياريًا إضافة اسم أيضًا. لا أعتقد أن رغبة المرء في مسح حقل الاسم (أو بيانات شخصية أخرى) هي سيناريو هامشي.
في الوقت الحالي، بمجرد أن يملأ المرء اسمًا، يصبح من المستحيل إزالته. كان هذا قيدًا من sync_sso قمنا بالتحايل عليه بمكالمة API إضافية لتحديث المستخدم، ولكن الآن لم يعد هذا يعمل أيضًا.
لقد نظرنا في الأمر، ولكنه يدفع بعض الأشخاص إلى افتراض أن اسم المستخدم الخاص بالشخص هو أيضًا اسمه الحقيقي: نحن ندير منتدى دوليًا وغالبًا ما لا يكون من الواضح ما هو اسم الشخص وما هو اسم المستخدم (بخلاف موضعهما في الواجهة).
يجب أن أذكر أنه إذا لم تخونني الذاكرة، فإن نفس المشكلة بالضبط تحدث مع إزالة صورة الرمز الشخصي للمرء من خلال sync_sso لأنني أعتقد أن هذا لا يعمل أيضًا - نحن نتحايل على ذلك من خلال توفير عنوان URL الخاص بنا لصورة رمزية افتراضية.
إذا كان هناك حقول متعددة قد لا يتمكن المرء من مسحها بطريقة ما، فربما مصفوفة (أو قائمة CSV) للحقول التي يجب مسحها/إعادة تعيينها؟
ما الذي سيتطلبه الأمر للتوصل إلى اتفاق بشأن طريقة لإنجاز هذا؟ يسعدني تنفيذ أي شيء من جانبي: معلمة جديدة، قيمة خاصة، استدعاء API ثانٍ. لكن الوضع الحالي، من وجهة نظري، ليس حالة هامشية. مثل @mentalstring أعلاه، أقوم بالمزامنة مع مصدر حقيقة خارجي حيث يكون تعيين صورة الملف الشخصي واسم العرض اختياريين. يُسمح للمستخدم بعدم امتلاكها. يسمح Discourse بعدم تعيينها. إذا لم تستخدم SSO، يمكنك تعيينها وإزالتها بحرية. DiscourseConnect يكسر هذا: بمجرد تعيينها، لا يمكن إزالتها أبدًا، وهو في رأيي خطأ (صغير جدًا).
أتفهم القلق بشأن تغيير البروتوكول حيث يعني الفارغ حاليًا عدم وجود تغيير. شخصيًا، أختلف، أعتقد أنه طريقة واضحة ومعقولة لتفسير البروتوكول والخطر ضئيل: سيكون من الغريب جدًا أن يتم تنفيذ الأنظمة بحيث ترسل دائمًا قيم الاسم و avatar_url، ولكن في بعض الأحيان تعيينها إلى فارغة، وتتوقع أن يعني ذلك الاحتفاظ بالقيمة القديمة. وإذا كان هناك أي منها يفعل ذلك، فإن النتيجة هي فقط إلغاء تعيين الاسم والصورة الرمزية، ويجب أن يكون إصلاحًا سهلاً.
ولكن على أي حال، لا أريد الجدال في هذه النقطة، ولكني أريد تقديم الحجة بأن هذه ميزة ضرورية. أنا على استعداد لتقديم طلب السحب (PR)، وأريد فقط معرفة الحل الذي سيتم قبوله.
شكرًا جزيلاً مقدمًا.
نظرًا لأن هذا يحدث مع name و avatar_url على الأقل وربما مع حقول أخرى (أعتقد website أيضًا؟)، فربما يكون هناك معلمة reset_fields مع قائمة بالحقول لمسحها بدلاً من عدة حقول clear_x فردية؟
بالنسبة لنا، سيكون من المفيد بالفعل إذا تمكنا من إصلاحه باستدعاءات إضافية لنقطة النهاية /u/{username}، ولكن هذا أيضًا توقف عن العمل في وقت ما.