admin emails for org pages/Source Jobs shouldn't be case-sensitive
Closed this issue · 6 comments
If this is not a terrible hassle it would be a nice wrinkle to smooth out somtime, @ryanpitts. (Copying @tsl-lindsay here for ref.)
SOM TIME sure
Yep! Aly Hurt's was in as AHurt@npr.org and she couldn't log in till I changed it to ahurt@npr.org. Sounds like maybe it's something more complicated than the case thing which was my first guess.
I'm going to doublecheck this, but I think that the hidden issue here was that the underlying user
account for Aly had not been automatically created.
In order to do the passwordless logins, each Organization Admin gets an associated user
account with a randomized password. When someone accesses the Jobs admin system, they get a login link via email, and then their password is randomized again so that no one can reuse that link. (This also means that you couldn't, say, take over someone's account by changing their password, because it's re-randomized after every use. Maybe overkill for this use case, but I think the only vector for problems here is if someone has complete access to a user's work email account, in which case they've got bigger problems than people posting fake jobs.)
Anyway, when an Organization Admin's email address is added or updated, it fires off a background task that makes sure there's a corresponding user
record for logins. Aly's user
record says it was created just this morning, so I don't think it was case-sensitivity that was preventing her from logging in, it was the lack of that randomized password record. When you changed the value and re-saved the Org record, that fired off the background process and restored the normal order.
I'm not quite sure why her user
record didn't exist before this morning. It could be that her email address was in that field before the passwordless system launched—I thought I ran a script to create password records for all the legacy addresses, but obviously something didn't get synced up here.
So two things I'll do today:
- run a db update to re-save each Organization Admin record, which will force a check for corresponding
user
records and create any that are missing - doublecheck that case-insensitivity works when people try to log in to the Jobs update page
OK, both of these tasks are complete.
- There were ~15 Organization Admin addresses that didn't have password accounts yet, and those are now created.
- I have Jobs admin access with "ryan@opennews.org," but I was successfully able to log in as "Ryan@OpenNews.org"
I think this issue is OK to close!
Thank you so much @ryanpitts! Awesome!