Recreating deleted original setup account makes them an administrator


(Mike Taber) #1

I have a user account that was used to install the application with a given email address. Let’s call it xyz@gmail.com. This email account was originally set as the administrator in the system when it was set up. After creating a second administrator account, the one using xyz@gmail.com was “demoted” to a regular user and then the account was deleted. Next, the email address was invited again to the system.

Upon logging in using xyz@gmail.com, the account becomes an administrator. It appears that if the account used to perform the install cannot be added back to the system without it becoming an administrator. This seems to be a bug but if not, there should at least be a way to change the default system administrator email address.

My guess is that something is being cached somewhere but I can’t figure out where. I edited the app.yml file to use a different email address. I also did a database dump after deleting this account and found that the email address still exists in the following tables:

  • email_logs - Seems to make sense, since it’s just a historical record
  • email_tokens - Shouldn’t this have been deleted when the user was deleted?
  • user_histories - Also sort of makes sense because it’s a historical record

I’ve gone so far as to:

  • update the token, email and expired values in the email_tokens table
  • update the app.yml file with a new address
  • restart discourse

Nothing seems to work to completely wipe this account from the system such that when it signs up again, Discourse doesn’t make the account with that email address as an admin.

Thoughts?


(Sam Saffron) #2

See

Remove the env var, rebuild container, delete user


(Mike Taber) #3

Thanks! That seems to have been exactly the problem. I spent forever trying to figure out what was going on under the covers.

Are there plans to consolidate many of these settings into the database? It’s painful to have to rebuild the entire thing to add/remove/update a developer account and it seems like there are three different places where this stuff is stored right now: users table, in the container (which to change must be rebuild) and the users.rb class.

I think part of why it took me so long to track this down is that it wasn’t obvious it was stored in the container itself. I hadn’t expected that, given the location of the other settings.


(Jeff Atwood) #4

This particular concern (the email address used to install Discourse) comes up very, very rarely. In fact this is the only time I have ever seen it come up.


(Mike Taber) #5

I think that where it’s stored isn’t so much of an issue as the fact that I simply couldn’t figure out what was going on. I wanted to test the system to see what an end-user would see. I wouldn’t have run into this issue if I’d created a new account as a non-admin instead of applying admin to an existing account and then deleting the original admin/developer account.

I can’t say I have a good answer for what to do. It’s technically an education problem in that there is a Developer email address specified in the config and it causes the system to behave differently for these accounts than all of the others.

In looking at the documentation here for installing, it states that users with this email address will be made into an administrator but it assumes that you realize the account isn’t yet created in the system. It’s far from obvious that creating a different admin account and deleting the original developer account doesn’t remove it unless you rebuild the container. There’s also nothing in the UI when logged in to denote that you’re a “Developer”. The closest you get is the mini profiler.

This is a problem @codinghorror alluded to last year here with regards to the lack of UI elements denoting a developer account. Had I seen something in the UI that said “Developer Account”, it would have been easier to track down, as opposed to searching for “why the original admin account in Discourse is made an admin even after deleting it”.

A technical option might be to prohibit deleting the developer account or preventing demoting it to a non-admin.