تعطيل التحقق عبر البريد الإلكتروني لـ SSO

مرحباً،

لقد قمت بإعداد Discourse لاستخدام Auth0 كمزود لتسجيل الدخول الموحد (SSO). المشكلة التي أواجهها هي أن المستخدم عند التسجيل يستقبل بريدين إلكترونيين للتحقق: واحد من Auth0 وواحد من Discourse.

هل هناك طريقة لتعطيل البريد القادم من Discourse؟

شكراً مقدماً

إذا كانت عناوين البريد الإلكتروني يتم التحقق منها بواسطة Auth0، فيمكنك تعطيل رسائل التحقق من Discourse عن طريق تحديد إعداد الموقع oauth2 email verified. هناك إشارة إلى هذا الإعداد في هذا المنشور: Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin - #33 by blake.

شكرًا على الإجابة @simon، لكنني أستخدم SSO وليس Oauth2

يُستخدم مصطلح SSO للإشارة إلى عدة طرق مختلفة للمصادقة، وقد تسبّب ذلك في ارتباك في مناسبات سابقة.

إذا كنت تستخدم تطبيق Discourse لـ SSO، فإن التحقق من البريد الإلكتروني يتحكّم فيه معامل SSO المسمّى require_activation. قم بتعيين هذا المعامل إلى "false" لتجاوز التحقق من البريد الإلكتروني.

شكرًا مرة أخرى @simon

أود تجنب تعطيله تمامًا. حاليًا قمت بإعداده بحيث يُرجع require_activation قيمة true أو false بناءً على ما إذا كان المستخدم قد تم التحقق منه عبر Auth0. هذا يعمل بشكل جيد، وبعد أن يضغط المستخدم على رابط التحقق في البريد الإلكتروني من Auth0، عند تسجيل الدخول مرة أخرى سيتم التحقق من حسابه في Discourse.

لذا، المثالي هو مجرد كتم البريد الإلكتروني ما لم أكن أفتقد شيئًا.

هذا منطقي. فإضافة ووردبريس الخاصة بنا تتعامل مع التحقق من البريد الإلكتروني بنفس الطريقة.

إذا كنت ترغب في معرفة كيفية استخدام قيمة require_activation من قبل منصة Discourse، يمكنك الاطلاع على هذا الملف: https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L81. ستلاحظ أنه عند تعيين require_activation إلى "false" عند إنشاء مستخدم جديد عبر SSO، سيتم إنشاء مستخدم نشط في Discourse. أما إذا تم تعيينه إلى "true"، فلن يتم تفعيل المستخدم حتى يضغط على الرابط الموجود في بريد تفعيل Discourse.

بمجرد تعيين حالة المستخدم إلى active في Discourse، فإن الشيء الوحيد الذي قد يتطلب إعادة تفعيل المستخدم هو إذا قمت بتفعيل إعداد الموقع sso_overrides_email وقام المستخدم بتحديث عنوان بريده الإلكتروني في موقع مزود SSO الخاص بك.

عند تعيين require_activation إلى "true"، فإنه يمنع أيضًا Discourse من مطابقة المستخدمين الحاليين مع المستخدمين من موقعك الخارجي بناءً على عنوان بريدهم الإلكتروني. وقد يؤدي ذلك إلى حدوث مشاكل عند تنفيذ SSO بعد أن تم إنشاء مستخدمين بالفعل في الموقع باستخدام حسابات تعتمد على اسم المستخدم وكلمة المرور.

شكرًا لك، هذا مفهوم، لكنني لست متأكدًا من كيفية منع إرسال بريد

لضمان إرسال بريد التحقق فقط من موقع مزود خدمة الدخول الموحد (SSO)، يجب على المستخدمين التسجيل في ذلك الموقع والتحقق من عنوان بريدهم الإلكتروني قبل تسجيل دخولهم الأول إلى Discourse. بعد ذلك، ستتمكن من تعيين معامل require_activation إلى "false" لهؤلاء المستخدمين. سيتم إنشاء حساباتهم في Discourse كحسابات نشطة ولن يتم إرسال بريد تفعيل Discourse إليهم.

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

يفترض DiscourseConnect أنك تقوم بالتحقق من عناوين البريد الإلكتروني على موقعك الإلكتروني. طالما أنك تفعل ذلك، لا تقم بتعيين معامل require_activation في حمولة SSO. إذا لم يكن هذا المعامل موجودًا في الحمولة، سيتم تسجيل دخول المستخدمين إلى Discourse دون إرسال بريد تفعيل إليهم.

نعم، لكن في هذه الحالة سيفترض Discourse أن المستخدمين قد تم التحقق منهم، وهو أمر قد لا يكون صحيحًا إذا ذهب المستخدم إلى المنتدى ونسى أو قرر عدم التحقق من بريده الإلكتروني. إذا تم تعيين require_validation إلى true في الموقع، فهذا يعني أن المستخدم لم يتحقق بعد من بريده الإلكتروني على الموقع، لكنه تلقى بالتأكيد رابط التحقق، لذا لا حاجة لـ Discourse لإرساله مرة أخرى، لكنه سيفعل ذلك بسبب هذا المعامل.

بشكل أساسي، تنشأ المشكلة فقط إذا ذهب المستخدم إلى Discourse قبل التحقق. لذا، حاليًا، عليّ الاختيار بين خيارين:

  1. يتلقى المستخدم بريدًا إلكترونيًا واحدًا للتحقق فقط، لكن Discourse سيعامله على أنه تم التحقق منه، وهو أمر غير مثالي لأنه قد لا يكمل عملية التحقق.
  2. يتلقى المستخدم بريدين إلكترونيين للتحقق، وسيتم التحقق منه بشكل صحيح من قبل كل من المنتدى والموقع. هذا الخيار أيضًا ليس مثاليًا، لكنه بالتأكيد أفضل من الخيارين.

هناك خيار ثالث: إضافة تبديل يعمل فقط إذا كان SSO مفعّلًا، مما يعطل بريد التحقق من Discourse (مع ترك صفحة خطأ تخبر المستخدم بأنه غير محقق).

في الوضع المثالي، عندما ينشئ مستخدم حسابًا على موقعك الإلكتروني، يجب أن تتحقق من عنوان بريده الإلكتروني من خلال طلب منه الرد على رسالة تفعيل تُرسل من موقعك الإلكتروني عند تسجيل المستخدم. إذا سمحت، لسبب ما، للمستخدمين بإنشاء حسابات على موقعك الإلكتروني قبل التحقق من عناوين بريدهم الإلكتروني، فيمكنك تعيين معامل require_validation بشكل مشروط في حمولة SSO. إذا كان المستخدم قد تحقّق من عنوان بريده الإلكتروني، فاضبط require_validation على false، أو ببساطة اترك المعامل خارج الحمولة. أما إذا لم يكن المستخدم قد تحقّق من عنوان بريده الإلكتروني على موقعك الإلكتروني، فاضبط معامل require_activation على true ليتم إرسال رسالة تفعيل له من Discourse.

هذا بالضبط ما أفعله، وهي مشكلة. على سبيل المثال، يسجل المستخدم ويستقبل بريدًا إلكترونيًا للتفعيل من الموقع الإلكتروني، لكنه بدلاً من فتحه وتفعيل حسابه، يقرر الانتقال إلى Discourse لسبب ما. حينها سيتم تعيين require_activation إلى true، لأن المستخدم لم يتم تفعيله بعد. لكن Discourse سيقرر أن المستخدم يحتاج إلى بريد إلكتروني آخر للتفعيل، وهو ما يمثل مشكلة، نظرًا وجود بريد إلكتروني للتفعيل من الموقع الإلكتروني بانتظار الفتح. يجب أن يعرض Discourse رسالة خطأ توضح للمستخدم أنه يتعين عليه التحقق من بريده الإلكتروني.