search

ponzu-cms / ponzu

Headless CMS with automatic JSON API. Featuring auto-HTTPS from Let's Encrypt, HTTP/2 Server Push, and flexible server framework written in Go.
https://docs.ponzu-cms.org
BSD 3-Clause "New" or "Revised" License
5.68k stars 386 forks source link

Delete superuser #240

Closed olliephillips closed 5 years ago

olliephillips commented 6 years ago

Hey Steve, do you think it a problem that additional users can delete the first "super" user? I wonder if it is not better to NOT offer the delete button on that user? One could see a situation where one is locked out by accident or malice?

nilslice commented 6 years ago

@olliephillips - I'll admit, the internal admin processes are probably where I spent the least amount of thought.. but yes, it could be possible that the initial "Admin user" is deleted, which could possibly be problematic.

Currently, there isn't a way to determine if the user is the initial "Admin user" and protect the record in some way (aside from it's ID being the lowest in value). If you have more thoughts on the user experience here and what scenarios we'd like to protect against, versus how flexible the system is and what we leave to the users, please feel free to document here!

olliephillips commented 6 years ago

It's always ID 1 is it not, since this user is created at first use?

I haven't looked at the code, but the logic would be if logged in user not id 1, don't show id 1 in the list of users, or at least suppress the delete option. I expect there is more to it though.

It's just an idea, based on having used other CMS systems which can differentiate between superuser and admin, and don't let admin edit/delete the superuser. Superuser or initial admin user is also highly likely to be the developer? So there may be other config options in the sidebar (Configuration, Addons?) that also are not relevant to admin roles who are editing/approving content, and might also be hidden, to avoid meddling?

See what others think?

nilslice commented 6 years ago

It's always ID 1 is it not, since this user is created at first use?

The absolute first user will have ID 1, but that isn't necessarily the admin account an arbitrary user may want to maintain as the "super user" per sé. For example, a developer could make the CMS, and have a temporary admin user (with ID 1), and then down the line hand off the system to a client, which would have their own admin user added (with ID 2). They may want to delete the developer's temporary admin user (ID 1), and maintain the new admin user (ID 2) as the "super user".. sort of contrived example, but just to illustrate my thought.

This is essentially why there is no built-in default behavior to differentiate any one admin from another.

I agree there should be more controls built in, especially as Ponzu becomes more mature and used in "real world" applications. Additional configuration options would be a great feature - I just want to get some more ideas for how it should be used before committing to one path forward.

olliephillips commented 6 years ago

Yes, I can see that, but on systems where superuser is a thing I'd just change the email and password to the new owner - assuming I don't need to stay the superuser for support/maintenance reasons - and in Ponzu this can be done. But yes, wider feedback required.

nilslice commented 6 years ago

Good point -- maybe for posterity it is worth noting here that the initial user (admin who initialized the system) is also the email address used to register the domain request for Let's Encrypt ACME calls for the TLS certificates. A suggestion would be to make this configurable as well, though how to update that with Let's Encrypt is something I'd need to look into further..

ghost commented 6 years ago

Very good point. I was also wondering about that for the certificate

olliephillips commented 6 years ago

Hey @gedw99, sorry I'm unclear though it's probably my fault - do you support a change that hides and/or prevents edit/deletion of "superuser" type functionality by subsequently created admins, or not?

ghost commented 6 years ago

i think that it depends on how it affects the Lets Encrypt certificates. I dont know and i would write a bit of code to change the super user and change the lets encrypt cert and see how that workflow pans out. If this test pans out, THEN i say go for it.

I just dont knwo how Lets Encrypt till react to the email being changed. I dont have enough experience with it.

0x0f0f0f commented 5 years ago

You can always get a completely new certificate when you are changing the email.

olliephillips commented 5 years ago

Closing this issue. No community feedback suggests this is a real problem. Please reopen if need to.