[Feature Request] Adding extra configuration to widgets

[jhollowe]

Description

I would like to be able to pass configuration to service widgets to allow greater variability in their presentation and function.
Currently, any extra keys added to the widget object in the services.yaml are removed within cleanServiceGroups().

I'm thinking there are two ways to allow this:

1. a global param like allowUncleanServices in settings.yaml which would allow any data in the widget's configuration to be available in the component.
2. allow each widget to specify what extra params it will use and clean each widget based on its type and alllowed params.

Which idea should I work on implementing (or do you have another idea)?

Other

No response

[shamoon]

Can you give a little more context? We’ve talked about different ways to do this, info widgets (as opposed to service widgets) for example, strip “sensitive” keys ie it’s more of a blacklist than a whitelist.

I guess one question is you foresee this being needed on a lot of widgets? I think idea 1 sounds a little complex for users. Again, a bit more context might help

[jhollowe]

I think there are a lot of info widget that could use at least a selector to define which of multiple things are included in the stats. There is fields but that is more a client-side filter of all the data that is there and not a "server-side" selection of what data to ask for from the origin.
I was originally asking since I'm looking into fixing the Proxmox widget and wanted the ability to select between getting the stats for the whole proxmox cluster or just the direct node that is in the url.

The same idea applies to a lot of widgets:

• traefik - which entrypoint(s) to consider for the stats
• qbittorrent - which category(s) to pull from
• plex - which libraries to include in the media count

What was the original idea behind cleaning/filtering the configuration? Is it just to not pass secrets to the client? If so, I think a way for a widget to provide keys that should not be passed to the client would be a cleaner way to hide secrets but allow widgets all the configuration they need to be fully featured.

[shamoon]

I am not the original architect but we have talked about it a bit. Yes the idea of cleaning as a whitelist was to sanitize things in a more protected forward-compatible way. And in general I know that a goal here is balance usefulness with complexity, i.e. ben didnt want every widget using its own bespoke set of options etc.

But of course I will defer to him on all this, and about the idea of refactoring the widget config. I know hes had a lot going on, but Im sure he will chime in at some point

[jhollowe]

currently, the service's config is not sanitized so configuration could go there. However, it makes more sense for config for the widget to be in the widget.

I totally get not wanting to make things complicated, but having the ability for a widget to have some configuration I think is a must. As long as whatever sanitization specialization is delegated to the widget, each widget can be as complex as it wants without interfering with the simplicity of other widgets.

ofc, if ben thinks differently, I'd love to discuss the best path forward.

[JazzFisch]

I know that when Ben and I were talking about this as well, one of the concerns was about leaking keys / secrets out to clients. From a security perspective an explicit allow list is the best approach as you aren't chasing each new change and then adding the appropriate changes to the deny list. Regarding your suggestion of delegating that responsibility to the widget itself, there's merit to that, but all it takes is a single typo and now a potential secret could be exposed to clients. It's a tough balance, and I'm glad we're having the conversation.

[github-actions[bot]]

This discussion has been automatically closed due to lack of community interest.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.