Create multiple user accounts with granular assignable AccessDomain (global, clientid's) and per-scope permissions: (read, readwrite, noaccess) for query log, rules, settings menus, filter protection mode, safe browsing, service blocking, adult filtering, all per-clientid options

[micfogas]

I have a feature request.

I would like the ability for the admin user to be able to create user accounts that provide granular control of access to the web UI/rest API. Access type would be either read-only, read-write, or no-access.

Separate controls by AccessDomain.

Each AccessDomain would have radio buttons for assigning a permission for the entire access domain: read-only (can view current status of the setting but can't change it), read-write (can view and modify the settings), no-access (user can't set or retrieve statuses for those items via rest API, and is not displayed at all on the web UI), and custom. Custom would allow granular permissions for individual settings, such as:

• globally: query log, custom rules, safe browsing, adult filtering, service blocking, app blocking
• per clientid (show each existing clientid as a separate AccessDomain): all clientid specific settings, broken down by section

Include additional quick settings button for quickly applying a permission to all clientid's. Only clientid's that the user has at least read access to, will be displayed to the user in the client settings section.

Permission for Client Settings would automatically be set to read-only if the user is assigned read-only or readwrite for any of the clientid permissions, and no-access would be greyed out and not permitted as long as this condition exists.

If the user is given readwrite to Client Settings under global, user will be able to add new clientid entries. The user would automatically be granted readwrite on creation but admin could modify them.

For Query Log, a global setting, readwrite would show the full query log. Read-only would forcibly filter the query log to only display queries for clientid's that the user has at least read-only permission to.

If the user is granted readwrite for filter protection for any client id, a quick setting button on the dashboard home page would toggle the filter protection for all of the users readwrite clientid's.

I know I have a few more specific things to mention but I'll post them when I remember them. This should be enough information for anyone reading this to understand and vidualize exactly what I'm requesting. User accounts with granular ACLs is something I've wished AGH had since day one.

The most wanted feature of all of this, and the reason I initially thought of this, is because I would like to give a family member access to turn protection on and off for their clients without changing the global setting. There are sites that get blocked that sometimes need to be accessed, and while I try to take the time to tune the custom rules by watching the query log while having them try to access the page, app, or site they need to access, I'm not always available to do that. And I don't expect them to understand the query log or try to figure out what needs to be manually unblocked. So allowing them to quickly turn off all filtering for their clients would be the best solution. That way, no one else is affected and they can leave filtering off for however long they need.

Adding this feature would be guaranteed to score you brownie points with my father, for what it's worth! 😀 The current solution is that I run a wire guard server on one of my cloud servers for myself. I made him an account (I use FireZone) and set it up on his computer for him. When either one of us need to quickly get around DNS filtering, it we're not sure if the problem is the DNS filtering, we just enable wire guard, do what we need, disable it again. The server has limited resources so throughput and latency are less than desirable (it's primary function uses minimal resources and it's not worth stepping up to a higher tier just to get better throughput for the little I use wireguard, which is either to get around DNS filtering, or when I'm traveling and not connected to my portable AP).

I thought about adding the feature myself and doing a PR, but it would take me a while to finish. I have a few other things going on that get my attention when I have time to really focus on something. But I did think through all of parts of my request and none of them would require heavy modification or rewrites of existing features. It's not that the access checks take a lot of code, but that theres a lot of settings, especially when working with individual clientid's, to place the checks.

Basic functionality of modifying assigned clientid settings via web UI would be a solid milestone. Then add granularity, and finally implement it into the API. At least, those seem like reasonable and logical milestones to roadmap.

Anyway, thanks for reading this! Hopefully we might see this go in!