Input helpers are great, however I avoid them because I don’t want users having the ability to change them via the UI. e.g. I create an input boolean that flags an ongoing process. I do not want the user to be able to turn off that input boolean, only an automation.
I envision an option (and field in yaml) that marks the input helper as ‘read only’.
This can currently be done via the UI / entities card, however that’s the only card that supports this and it’s not easy to set up. It can only be set up via yaml. Instead of forcing this at the UI level, make it a backend option where only service calls can used with the helper.
This WTH is solely about a new entity Types/Option. Fair enough, if this is whats desired.
However, when thinking about an access control with granular rw Management, this Demand would be solved as well.
I consider the WTH as a Brainstorming-Type. Any “This wont be done / is too much Work” stops such Processes.
Your definition of it may be that, however the owner of HA said that its likely that will never be added to HA at the entity level. From what I’ve gathered, we will likely see user control for full dashboards, where the dashboard itself is restricted without edit abilities.
I.e. A page you can display on a tablet that only gives you the ability to control entities, not configure them (and no other access to main settings).
Beyond disappointing understandable it’s huge work… but… Very very disappointing… respectfully that’s not access controls and it should not be said that it is.its UX bandaid and will lead someone to pain with a false sense of security.
I still think we need read only views but we also need. ‘I don’t care how you got here you still should not be able to flip this switch.’
So im voting for but STILL need real access controls.
Disappointing, yes. But that’s what’s been currently said. That doesn’t mean it won’t happen. I however am not expecting anything beyond a locked dashboard, I recommend having the same expectations.
True. And you know I will continue to lobby for full zero trust, and real fido compatibility in login providers (using pre-built trusted libraries.)
Is what we’ll need to be able to have medical data in HA safely.
But read only is also a valid use case and one of the security layers true rbac needs so this has to happen too…
And unless there’s entity level view and change I will continue to refuse to call it access control… Like backward incompa…breaking freaking change still can’t do it.
Gah. That’s easy to bypass via websocket or HTTP API — heck, injecting some DOM on a dashboard will allow for full control of any entity or call any (non-admin-only) action.
I guess the community will have to maintain a HACS or premium add-on to do it right.
No, because long push on a tile brings up the entity details dialog, from where you can change anything (that doesn’t require admin).
There’s a bunch of ways to get at this dialog, and another bunch of ways to alter entity state. These need to be cordoned off, for proper access control.
…. in my dashboard, if I set the interactions to “nothing / nothing / nothing” on a tile, there is no way to go to the entity details dialog. Forgive me if I missed something : I’m a beginner.
In my dreams, adding a numeric input as a feature set to a future “read-only slider” will change these tiles to progress bars or horizontal gauge.
For security reasons, I would personally not expose sensitive inputs to a dashboard, but set a sensor to replicate the value of the slider with a template. But this would be a workaround, not a WTH.
