Obviously I’m testing with several accounts I created just for this purpose (using virtual machines and other browsers and too much time testing 
).
I think I resolved the issue on my end. It had nothing to do with Discourse.
There’s a bit of code in my site’s footer that checks – for users whose email has been verified – if they are logged in to Discourse already and, if they aren’t, logs them in. This informs Discourse of users’ info, even if they don’t visit the forum itself.
Alas, this chunk was being accidentally cached so, of course, it wasn’t firing because it had been cached when no user had logged in. My bad! 
3 إعجابات
This is probably the best place still to mention that there are cases when Discourse drives me absolutely nuts.
I happen to have several “users” that are not real. Whether they are read-only accounts for a specific hidden category, anonymous beyond the capabilities of Discourse or whatever should not matter. Some of these are automatic and created on the fly as needed (and reused in a queue).
Problem is, they have been added using a “noreply” email. That email does not exist anymore so Discourse is spamming out admin mails saying this email bounced, all the time, for each of these users and the moderators are now starting to go nuts.
Now, if I go in and change that email to an existing no-forward, no-store email, Discourse refuses to do it without sending a mail to said email asking for confirmation… so no changes are made. Anyone see the problem here? 
So I have two options I can think of:
Log in as each user using SSO to force an email change (which hopefully does not require confirmation, haven’t actually tried, would be too tedious).
Go to the preferences of each such user and change email notifications and summary digests to never, ever. And every time a new temporary user gets created, I need to remember to do the same.
Maaaaan. If I as an admin change an email for a user, there is no need to ask the user to confirm the email. Any user will hopefully contact me if I actually messed up which is very unlikely. Besides, these days I just let the users change their emails at will, less trouble for a poor admin. And I understand there is a risk that the user will never be able to login or notify anyone again but obviously they can mail the site help as such.
إعجاب واحد (1)
Why not use the sync_sso endpoint to fix all the emails via api?
إعجابَين (2)
Not sure what you mean by this. Are you talking about the setting “sso overrides email”?
That would only take effect when/if the user actually logs in. So emails would still bounce while the email is wrong.
If you are possibly talking about “POST admin endpoint /admin/users/sync_sso to synchronize an SSO record” that would mean I would have to force one or all users from the SSO software I guess. Given the problems with SSO emails syncing it’s not the first option I would try.
Anyway, because of the problem described earlier in this topic I now have “sso overrides email” off and let users change their emails themselves. So I don’t want to override from SSO anymore.
But all this is missing the point, that the users bouncing mails are generated on the fly, as needed. The easiest way would be to allow a change to the email without authentication (at least for admins - or admins would have a choice).
Side note: I have tried giving an empty email address but the system does not allow for that. I understand the email address is so critical is should not be empty. BUT, if you really give an empty email (at least as an admin), one could assume you know what you are doing.
Just to confuse things more, I actually have users that do not have an email account, only access to a browser. Think refugees here and you might understand why. It is far easier to just allow someone to login and read instructions in their own language than to try and explain to them they need to make a gmail account or something.
In any case, this is theoretical, I doubt many people have the same problem. I would say it’s simply too strict even for admins, IMHO.
(sorry about the reply time, with more free time the world would be perfect)
إعجاب واحد (1)
That would allow someone to hijack an admin’s account without their knowing. Though your edge case for users without access to email makes some sense, it seems far-fetched to think that admins would be people who don’t have the ability to receive email.
إعجابَين (2)
Admins have email addresses. Not sure where you got the idea they would not have (my bad writing probably ).
The case was for an admin to be able to change other user’s emails without the need to authenticate.
إعجاب واحد (1)
So I’m trying to do this - the use case is a user has changed their email in the SSO system, however they now can’t log in since there’s another account of theirs that uses their new email address already. SSO refuses to update the email (even though we have sso_overrides_email on) because email addresses must be unique across accounts. I don’t want to delete the account without the SSO record as that has posts associated with it. And if I turn off sso_overrides_email to change the email manually, I can’t make it some broken email since Discourse insists on validating it.
I see there’s a way to merge users but a) it’s a rake task and we’re hosted with Discourse, do I contact support to do that? b) there’s comments about needing to swap the primary and secondary email addresses.
إعجاب واحد (1)
I’m in the same boat @trs80. Did you ever find out if there is a way to workaround this limitation of the merging?
I’ll have to check my email but support have generally been pretty good with resolving these issues.
إعجابَين (2)
“تعيينه لتجاوز رسائل البريد الإلكتروني”
هل هذا هو إعداد “تجاوزات المصادقة للبريد الإلكتروني”؟
إعجاب واحد (1)
ليس سيئًا أيها الذكاء الاصطناعي، سعيد بهذه الإجابة:
AI explainer on auth overrides emails
AI
sam:
ماذا يفعل بريد تجاوزات المصادقة؟
gpt4_bot:
Reading context for: auth_overrides_email
يُعد إعداد الموقع auth_overrides_email في Discourse مسؤولاً عن التحكم في سلوك البريد الإلكتروني فيما يتعلق بموفري المصادقة الخارجيين. عند تعيينه على true، يقوم هذا الإعداد بما يلي:
- يتجاوز عنوان البريد الإلكتروني المحلي بعنوان البريد الإلكتروني المقدم من موفر المصادقة الخارجي (مثل SSO، OAuth) عند كل تسجيل دخول للمستخدم.
- يمنع المستخدم من إجراء تغييرات محلية على عنوان بريده الإلكتروني ضمن إعدادات حساب Discourse الخاص به.
تنطبق هذه الميزة على جميع موفري المصادقة المكونين على موقع Discourse. هذه الميزة مفيدة عندما تريد الحفاظ على اتساق البريد الإلكتروني والتحقق من الهوية للمستخدمين الذين يسجلون الدخول عبر خدمات خارجية.
ومع ذلك، يجب على المستخدمين توخي الحذر مع هذا الإعداد، حيث يمكن أن تحدث اختلافات بسبب تطبيع عناوين البريد الإلكتروني المحلية. هذا يعني أنه إذا كان هناك اختلاف في كيفية تنسيق أو معالجة أنظمة البريد الإلكتروني الخارجية و Discourse لعناوين البريد الإلكتروني، فقد يؤدي ذلك إلى عدم تطابق أو مشكلات في ربط الحساب.
القيمة الافتراضية لـ auth_overrides_email هي false، مما يعني أنه افتراضيًا، لا يتجاوز Discourse رسائل البريد الإلكتروني المحلية برسائل البريد الإلكتروني للمواقع الخارجية عند كل تسجيل دخول، ولا يمنع المستخدمين من تغيير عناوين بريدهم الإلكتروني.
عند تمكين هذا الإعداد، فإنه يؤثر على أذونات المستخدم المختلفة، بما في ذلك عدم القدرة على تعديل عناوين البريد الإلكتروني في حالات معينة، كما تتم إدارتها بواسطة نصوص حارس الموقع وحارس المستخدم البرمجية. بالإضافة إلى ذلك، يؤثر الإعداد على كيفية عرض حقول البريد الإلكتروني وما إذا كان يتم تقديم تعليمات للمستخدمين فيما يتعلق بتغييرات عنوان البريد الإلكتروني داخل واجهة المستخدم.
إعجاب واحد (1)
أواجه مشاكل هنا أيضًا. يستمد Discourse معلومات SSO الخاصة به من موقع WordPress الخاص بي، وتم تمكين auth_overrides_email.
ومع ذلك، عندما أقوم بتحديث عنوان البريد الإلكتروني للمستخدم في WordPress، لا يتم إجراء أي تغييرات على Discourse.
لقد حاولت إيقاف تشغيل auth_overrides_email، وبينما أزال التعليق الذي يشير إلى أنه تتم إدارته بواسطة موفر مصادقة، لم يكن هناك أبدًا رمز قلم بجوار عنوان البريد الإلكتروني، سواء بالنسبة لي كمسؤول أو عند انتحال شخصية المستخدم (وهو ما فعلته عدة مرات قبل إيقاف تشغيل الإعداد لمحاكاة تسجيل الدخول/الخروج الذي تم اقتراحه أعلاه). كل ما تمكنت من فعله هو إظهار العنوان.
لقد قمت بإعادة تشغيل auth_overrides_email وتغيير العنوان مرتين أخريين في WordPress (إلى شيء آخر والعودة إلى ما ينبغي أن يكون)، دون أي تغيير.
اقتراحات؟
لدي نفس المشكلة. هل هناك طريقة لتغيير البريد الإلكتروني للمستخدم في قاعدة بيانات Discourse؟ كيف أفعل ذلك من سطر الأوامر؟
إعجاب واحد (1)
عادةً ما أحتاج إلى تمكين emails_editable، ثم تعطيل auth_overrides_email، ثم تغيير البريد الإلكتروني.
إعجاب واحد (1)
إذا أجبرتهم على تسجيل الخروج بحيث يضطرون إلى تسجيل الدخول مرة أخرى، فهل يتم تمرير عنوان البريد الإلكتروني الجديد إلى Discourse؟
إعجاب واحد (1)