Needed some time to actually look at this and trying to figure it out. And to write up what I have tried and failed with.
I don’t understand what “changing it at the source” means. The SSO database already has a different email but it does not automatically propagate to Discourse when you log in. I actually published the code I’m using ages ago here:
Ok, first of all, this is the only way I have managed to finally change the email of an user.
The culprit for me seemed to have been I provide the email in each sso authentication. I would then expect it to change in any subsequent login (since it works when a user gets registered for the first time I pretty much think the “&email=xxxx” part in the nonce (IIRC) should update it properly).
In the login setting the “sso overrides email” was on. So changes in the sso database should get reflected properly next time you log in? Logging off and logging in to force a new login has no effect.
But, once the “sso overrides email” is off, both the user and an admin can edit the email.
Hey presto! Hopefully this solves the problem for a few other people as well?
Makes sense, wonder why I missed that option earlier. Probably because I thought that exact option should handle it correctly.
So, is the “sso overrides email” the actual bug (apart from the process being overly complicated )?
Just reading the code it would seem so, sso emails do not propagate after the initial registration.
@sam, if needed I can give you the opened up sso details (uncoded message parts) but this is probably something that can be tested without me messing around any further.
I had some trouble with this issue as well, but I don’t have good enough data to figure out what went wrong. We changed the user’s email at the source. I gave her a link to log out of Discourse (which also logs her out of the source system), just in case, and a link to login again in at the source using the new email.
She told me that she followed my instructions (and she did, from what I could tell based on her activity on Discourse), but her email address remained unchanged on Discourse. A few days later I checked Discourse again it was changed. I don’t know what caused the delay. Is there some cache I should clean when I know users have changed their emails?
Actually, when I re-opened the issue earlier today, I only found one user that had the old email. I thought I had more than one.
And looking backwards in this topic, one of the “bad” users was frbulllover and her address was now correct (11 days later).
So during some logins, the sso override seems to work. Since I have a link to the actual sso code in this topic as well one can see that the email is always given. Hmmmmm…
I have obviously logged in and out trying to fix this.
Could it be the 2 week login cookie has to expire before the sso override takes place??? A simple logout/login is not sufficient?
Kicked out the user twice and both times the email changed correctly.
Maybe not a cookie then. Or maybe things just work the way they are supposed now. I haven’t updated Discourse for a month though not to get a “fix” by mistake as I want to figure out the real reason for things not working.
The really weird part using the admin logout for a user is that it crashed the SSO solution (once). I don’t have any logout actions enabled! I’ve had this happen once before and it took me ages to figure out how to fix it (did the domain crash, etc). Basically the sso solution .NET 4.6 environment crashes and has to be restarted (using Lfchosting as my hosting environment and I have plenty of software there NOT crashing, ever). I’m seriously wondering whether kicking someone out and the subsequent automatic login via SSO happens several times in a row or in some weird manner differently from the normal authentication that then makes the .NET environment crash?
Every time things that make no sense happen I should of course check all logs, actually log in to discourse on the server and try to figure it out. I just don’t have time for this anymore today… need to get some work done.
Weird! The fact that force-logging out the user makes me think that he didn’t really log out before, so no SSO happened (he just kept on using his old session).
(I have no idea about the crashes, though.)
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!
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.
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)
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.
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.
.
).
