تعيين name claim بدلاً من preferred_username claim إلى اسم المستخدم (الاسم المستعار)

هل يعرف أحد ما إذا كان من الممكن تعيين المطالبة name بدلاً من المطالبة preferred_username إلى اسم المستخدم (اللقب) المعروض أثناء التسجيل والذي يظهر في النافذة المنبثقة “إنشاء حساب”؟

إليك المعلومات التي نتلقاها من Keycloak:

{
 ..
  "scope": "openid email",
  "sid": "f0f20a2a-19e5-4581-8a45-c1250376f226",
  "email_verified": true,
  "name": "Ted Bush",
  "preferred_username": "tb",
  "given_name": "Ted",
  "family_name": "Bush",
  "email": "ted.bush@example.com"
...
}

بشكل افتراضي، يتم استخدام preferred_username (في هذا المثال، “tb”) كاسم مستخدم (لقب).

ومع ذلك، نود تكوين التكامل بطريقة يتم بها استخدام name (“Ted Bush”) كاسم مستخدم (لقب) بدلاً من ذلك.

شكرا.

أرى إعداد “استخدام الاسم الكامل للمستخدم عند اقتراح أسماء المستخدمين” في قسم إعدادات المستخدمين. ولكن يبدو أنه ليس له أي تأثير بالنسبة لـ OpenID Connect؟

أم أن هذا يعمل لدى أي شخص؟

نعم، إنه يعمل لدي عند اختباره باستخدام خادم Google OAuth2 كموفر OpenID Connect.

أعتقد أن المشكلة التي تواجهها تتعلق بكيفية عمل كود اقتراح اسم المستخدم في Discourse. يقوم Keycloak بإرجاع preferred_username. إذا تم تعيين preferred_username في معلومات المستخدم التي تم إرجاعها من موفر الهوية، فإنه له الأسبقية على قيمة حقول name أو given_name/family_name.

للإشارة، تحدث المشكلة هنا (يتم تعيين preferred_username كقيمة لـ username في طريقة يتم استدعاؤها قبل هذا):

ثم هنا:

نظرًا لأن قيمة preferred_username هي الوسيط الأول الذي يتم تمريره إلى كود اقتراح اسم المستخدم، فسيتم استخدامه. هذا يعني أن إعداد use_name_for_username_suggestions ليس له أي تأثير في هذه الحالة. أعتقد أنه كان مخصصًا لمعالجة حالة عدم تمرير preferred_username مرة أخرى من موفر الهوية.

لا أرى حلاً بديلاً جيدًا لهذا، إلا إذا كان بإمكانك منع تمرير preferred_username إلى Discourse من Keycloak.

إعجاب واحد (1)

@simon، أنت على حق؛ لقد تحققت مما ذكرته باستخدام نسخة اختبار من Keycloak. عندما أقوم بتكوين Keycloak لتجاهل preferred_username عند تمريره إلى Discourse، يتم بالفعل استخدام الاسم الأول والأخير من قبل مقترح اسم المستخدم في Discourse.

ومع ذلك، لا يمكننا تكوين Keycloak الإنتاجي الخاص بنا بهذه الطريقة، حيث أن تكوين العميل مشترك مع العديد من العملاء الآخرين، وليس فقط Discourse.

سيكون من المفيد وجود طريقة للتأثير على هذا السلوك داخل المكون الإضافي.

إعجاب واحد (1)