User settings page

[readmemyrights]

As of writing this, administration of users is split up into multiple pages like /admin/user/disable, /admin/user/schedule, and so on. Each page asks you to type in a username, secret, and other information to change the users settings.

The trouble with this approach is that there is no way for the page to know which user is going to be changed before the request is sent. This makes it impossible to prefill fields based on current user settings, mistakes are likelier when typing in a username, and there is a lot of duplication within the code used to implement the pages.

The idea is to have a single page such as /admin/user/[id] that would display the settings for a user, prefill fields with current settings,, and have a page /admin/user which would display a list of users and a search box to look through them.

An incomplete list of questions:

• How does secret fit into all of this? Would it there be a field on the settings page again or would we implement sessions for administrators as well?
• Will we leave this for a future version of indexomator? (future meaning after 1.0)
• How do enable all / disable all buttons fit into this?

[aleksasiriski]

We could rename "admin" into a "superadmin" and his only role would be to create new "admin" accounts using the secret. Afterwards, we could implement admin sessions like we did for users (with stricter rules for password creation and possibly 2FA).

[readmemyrights]

It's overly complicated in my opinion, most deployments are going to be managed by one admin or at most a small local team of them, and having multiple admin accounts could only open more security holes and make it harder to use. I propose to just allow log in using the secret, perhaps add optional OTP for 2FA.

This is arguably out of the scope of this discussion, perhaps we should move this to a separate discussion?

[matijakljajic]

If I may barge in, I think this does not need that much of an expanded discussion.

Instead of multiple secret inputs on every page, we can lock the entire admin panel with the secret system we currently use.

It's a good idea to have a table for users from which we can go into a page for a picked user where it's going to just pre-populate the fields for already existing forms.

It's just a bit of UI reorg for the admin part where almost all components already exist in the dashboard in some form or another and which can be reused, it's nothing else when you look at it from that perspective.

Admin accounts and 2FA can be done in the future, but we have to consider what's a priority and what's not at this current moment.

Feel free to discuss further if you want of course, all this is just a suggestion.

[aleksasiriski]

I propose we create sessions for admins by froviding the secret, but that those session don't have a cookie set in the browser but instead use session storage so that whenever you close the tab it logs you out.

This way we maintain no fear of someone's cookies getting stolen as it is a common type of attack.