Hey,
I’ve set up discourse to use Auth0 as the SSO provider. The problem I have is that when a user registers they are recieving two verification emails. One from auth0 and one from discourse.
Is there anyway to disable the one from discourse?
Thanks in advance
If email addresses are being verified by Auth0, you can disable Discourse verification emails by selecting the oauth2 email verified site setting. There is a reference to that setting in this post: Configure sign up and log in with Auth0 using the OAuth2 Basic Plugin - #33 by blake.
Thanks for the answer @simon but I’m using SSO not Oauth2
The term SSO gets used for a few different authentication methods. This has caused confusion a few times in the past.
If you are using the Discourse implementation of SSO, then email verification is controlled by the require_activation SSO parameter. Set that parameter to "false" to bypass email verification.
Thanks again @simon
I want to avoid disabling it completely. At the moment I have it set up so that require_activation returns true false based upon whether they have been verified by auth0. This works fine and after they have clicked on the auth0 email the next time they login they get verified on discourse.
So ideally it would just be suppressing the email unless I’m missing something
That makes sense. Our WordPress plugin handles email verification in the same way.
If you want to see how the require_activation value is used by Discourse, have a look at this file: https://github.com/discourse/discourse/blob/master/app/models/discourse_single_sign_on.rb#L81. You’ll see that when require_activation is set to "false" when a user is first created via SSO, an active user will be created by Discourse. If it is set to "true", the user will not be activated until they click the link in the Discourse activation email.
Once a user is set to active on Discourse, the only thing that should cause a user to need to be reactivated is if you have enabled the sso_overrides_email site setting and the user updates their email address on your SSO provider site.
When set to "true", require_activation also prevents Discourse from matching existing users to users from your external site based on their email address. This can cause issues when SSO is implemented after users have already been created on the site with username/password account creation.
Thank you that makes sense, however I’m not sure how this stops the “verify email” email from discourse getting sent?
I just want the one from auth0 to be sent
To only have the verification email sent from your SSO provider site, users will need to register on that site and verify their email address before they first login to Discourse. You will then be able to set the require_activation parameter to "false" for those users. They will be created as active users on Discourse and not get sent the Discourse activation email.
هذا لا يبدو منطقيًا. كيف يمكنني إجبار المستخدمين على التحقق من بريدهم الإلكتروني قبل أول تسجيل دخول إلى Discourse؟
موقعي الإلكتروني يتولى بالفعل عملية التحقق من البريد الإلكتروني، فكيف يمكنني تعطيل إرسال Discourse لرسائل التحقق، مع إظهار رسالة للمستخدم تفيد بأنه يحتاج إلى المصادقة؟
يفترض DiscourseConnect أنك تقوم بالتحقق من عناوين البريد الإلكتروني على موقعك الإلكتروني. طالما أنك تفعل ذلك، لا تقم بتعيين معامل require_activation في حمولة SSO. إذا لم يكن هذا المعامل موجودًا في الحمولة، سيتم تسجيل دخول المستخدمين إلى Discourse دون إرسال بريد تفعيل إليهم.
نعم، لكن في هذه الحالة سيفترض Discourse أن المستخدمين قد تم التحقق منهم، وهو أمر قد لا يكون صحيحًا إذا ذهب المستخدم إلى المنتدى ونسى أو قرر عدم التحقق من بريده الإلكتروني. إذا تم تعيين require_validation إلى true في الموقع، فهذا يعني أن المستخدم لم يتحقق بعد من بريده الإلكتروني على الموقع، لكنه تلقى بالتأكيد رابط التحقق، لذا لا حاجة لـ Discourse لإرساله مرة أخرى، لكنه سيفعل ذلك بسبب هذا المعامل.
بشكل أساسي، تنشأ المشكلة فقط إذا ذهب المستخدم إلى Discourse قبل التحقق. لذا، حاليًا، عليّ الاختيار بين خيارين:
هناك خيار ثالث: إضافة تبديل يعمل فقط إذا كان SSO مفعّلًا، مما يعطل بريد التحقق من Discourse (مع ترك صفحة خطأ تخبر المستخدم بأنه غير محقق).
في الوضع المثالي، عندما ينشئ مستخدم حسابًا على موقعك الإلكتروني، يجب أن تتحقق من عنوان بريده الإلكتروني من خلال طلب منه الرد على رسالة تفعيل تُرسل من موقعك الإلكتروني عند تسجيل المستخدم. إذا سمحت، لسبب ما، للمستخدمين بإنشاء حسابات على موقعك الإلكتروني قبل التحقق من عناوين بريدهم الإلكتروني، فيمكنك تعيين معامل require_validation بشكل مشروط في حمولة SSO. إذا كان المستخدم قد تحقّق من عنوان بريده الإلكتروني، فاضبط require_validation على false، أو ببساطة اترك المعامل خارج الحمولة. أما إذا لم يكن المستخدم قد تحقّق من عنوان بريده الإلكتروني على موقعك الإلكتروني، فاضبط معامل require_activation على true ليتم إرسال رسالة تفعيل له من Discourse.
هذا بالضبط ما أفعله، وهي مشكلة. على سبيل المثال، يسجل المستخدم ويستقبل بريدًا إلكترونيًا للتفعيل من الموقع الإلكتروني، لكنه بدلاً من فتحه وتفعيل حسابه، يقرر الانتقال إلى Discourse لسبب ما. حينها سيتم تعيين require_activation إلى true، لأن المستخدم لم يتم تفعيله بعد. لكن Discourse سيقرر أن المستخدم يحتاج إلى بريد إلكتروني آخر للتفعيل، وهو ما يمثل مشكلة، نظرًا وجود بريد إلكتروني للتفعيل من الموقع الإلكتروني بانتظار الفتح. يجب أن يعرض Discourse رسالة خطأ توضح للمستخدم أنه يتعين عليه التحقق من بريده الإلكتروني.