-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
web configuration UI #35
Comments
(I also considered the names "capabilities" and "scopes", but I think "permissions" is the most widely understood.) This is increasingly necessary as the web API becomes more capable. Among other things, it allows: * non-administrator users who can view but not access camera passwords or change any state * workers that update signal state based on cameras' built-in motion detection or a security system's events but don't need to view videos * control over what can be done without authenticating Currently session permissions are just copied from user permissions, but you can also imagine admin sessions vs not, as a checkbox when signing in. This would match the standard Unix workflow of using a non-administrative session most of the time. Relevant to my current signals work (#28) and to the addition of an administrative API (#35, including #66).
Regarding the final bullet point about Unix domain sockets, see: seanmonstar/reqwest#39 |
There are a lot of usability problems in the existing config interface, as described in this comment. I'd love to address those in a web based-UI, where there's more screen real estate for explanation. |
I'm willing to tackle the UI side of this. However there is AFAIK currently no exposed JSON API to manipulate the config data, so this would be a prerequisite. Should that be split out as a separate issue? I have no Rust experience. |
Awesome. Very glad to have your help. I Filed #153 for the server-side work, and I'll start working through it soon. |
@sky1e continuing our conversation from #276:
I actually am imagining having it configured only over HTTP (never having to shut down the server), and dropping the TUI/ Can you be more specific about the advantages you see of a terminal-based UI? I mostly see one: it can be a way of bootstrapping authentication. I've been planning to address that in a few ways:
|
The TUI
moonfire-nvr config
is a decent way of configuring the system for now, but long-term I'd like all configuration to be done through the web UI:new JSON interfaces to define(split to JSON API for configuration #153)server refactoring: the(split to JSON API for configuration #153 also)Streamer
andSyncer
interfaces in the server don't have any teardown logic, aren't exposed to the web UI in any way, etc.needs to be authenticated,[edit: this is done as part of user authentication #26] and have a notion of a config permission (easy)moonfire-nvr config
. I'm thinking a simple CLI for user manipulation which authenticates to the server over a Unix domain socket protected via file permissions orSO_PEERCRED
.The text was updated successfully, but these errors were encountered: