Hide sensitive site settings

(Brian Alexander) #1

It would be nice if sensitive site settings (like s3_secret_access_key) were not visible on the /admin/site_settings page. If this is something that the maintainers of Discourse are interested in, then I can submit a pull-request. Please let me know. Thanks!

(Sander Datema) #2

They used to be in a separate file. They were moved by @zogstrip a while ago. I think the whole admin area is heavily under development, so for now it might be ok the way it is. Collecting all the configuration variables is more important now than having them look nice.

(Brian Alexander) #3

@Sander78 I was thinking more from a security standpoint than from a standpoint of having it look nice.

(Sander Datema) #4

I understand, but then I have the same opinion: first you need to know what needs to be configured and then you can make it secure.

So in the end I agree with you, but I wonder if it’s already this soon on the roadmap.

(Sam Saffron) #5

Site settings are only visible to admins, mods can not see them.

Conceptually admins are the people with keys to the castle, they can do anything to a site.

The difference between admins and mods
(Allen - Watchman Monitoring) #6

I’m working on a new deploy of discourse (it’s up and running in just a few hours :slight_smile: ) but there’s more that I want Discourse to do, and I don’t have the chops.

To that end, I’m bringing in a colleague to help tweak & create pull requests. He’ll need admin access, but that does’t mean he needs to see the POP password, or github github_client_secret etc etc.

It would give me ~15 or so less keys to worry about if all the ones here were displayed as bullets once saved.

(Allen - Watchman Monitoring) #7

Similarly, storing the sensitive values in the settings change log is something I was surprised to see… we normally obscure these thing from getting committed to logs and repos and such.


(Sam Saffron) #8

This is a bug, we should definitely have settings obscured from the production logs

edit on second thoughts I would only consider this minor, the reason we scrub user passwords is cause we don’t know them and should not know them. We store hashed passwords that need to be brute forced if you are ever going to reverse them, something that is impractical for any good password a user chooses.

The creds stored in site settings are stored in clear text, we have no other option. Only admins have access to them and to the logs, there is no information leak. That said I am fine to scrub them out of the production log file.

(Régis Hanol) #9

That is now done.


(Jeff Atwood) #10