I think the easiest way to implement this would be in two parts. It wouldn’t give all the features everyone is requesting, but it would represent something usable for most of the desired cases.
PART 1 (easy?):
We already have “tabs” (groups with view: yes). If Home Assistant provided a URL to a tab view with no sidebar, and no developer tools, this would, at least in the view, limit the abilities of that particular page.
Since the web interface actually calls the API, the entire set of devices would still be available, however, the view of them on the presented web page would be limited.
PART 2 (harder?):
Allow different API passwords for each tab view. The API calls would have to allow for more than one password, and if the master password was not used, the entity IDs being acted on would have to be cross referenced with the entities available to the api password as identified by the “tab”. Only a single level of permissions checking would be needed. If a tab has access to a script, but not a light, and the script controls that light then, through the script ONLY, that password has access to that light. An exception should be made for groups, where, if a group is part of the tab, the entities in that group would be included in the permissible entities.
In the last days I implemented, as a proof of concept and discussion base, basic support for multiple API users; allowing to restrict (write) permission for the switch/command_line component (in the backend only, and only for the command_line component as of now).
If logged in as a user that does not have 'w’rite access to a switch/command_line entity then the state will not be set in the backend, even if the GUI currently allows to toggle the state.
move the has_perm() method and contains_perm() function from components/switch/command_line.py to a better place - an own Permissions class or just to the Entity class?
generalize, to support ‘permissions’ configuration/attribute for all components, starting with those that are more likely to be restricted.
does it make sense to store the permissions info, i.e. which user can access which entity, in a central place - inside the “State” class? E.g. on accessing the state via API from a remote HA instance, the permission info could be used to completely deny access to certain components, those where api user does not even have 'r’ead access; and could deny changing the state if api user does not have 'w’rite access. * In the frontend components without at least 'r’ead permission could/should be hidden.
I changed my mind on having multiple users or account.
Why?
After having smart home for almost a year now, I realize one thing; nobody wants to walk up to a wall to control the lights.
The best thing to do that is already in our hand; smartphones.
But then, nobody likes to open up another app to do just that. It takes time (even few seconds can be frustrating) and interrupt the user experience flow. Since everyone in the house is already receiving notifications to their phone via Telegram, it only make sense if they can control the house from the same place.
With HASS Telebot, I can do just that. From this, I manage to modify the code and have this…
Each members will have different keyboards/options.
So with this, I don’t need multiple users anymore.
A feature I would also love to see added so that kids can only control their room and select communal ones. Could also be used in a workplace to prevent everyone access to say the server room lighting or managers office lighting. A simple MySQL db with tables that link devices/groups to users should be possible??? The users can then save their password on their device so that logon is easier if they choose.
You can accomplish the multi-user with various passwords and limited controls with what is already available. Say you want two (or more) setups for parents and kids. You can do it with the following:
Setup two (or more) instances of HomeAssistant in two different vert environments (or on different computers) and setup an MQTT server.
For MQTT components, you can just setup both with different configuration.yaml files for the different passwords and controls that you want each to have. For the parent, you can keep discovery on and the kids one you can turn off the discover and put all the desired components in the yaml files.
For non MQTT components, it gets a bit trickier as some devices will only write to one instance or receive from one instance and then you need to setup that device to mainly be controlled by the parent instance.
To setup communication, send messages back/forth from/to the child instances to communicate with the parent instance. In those cases you setup automation in both (or all) instances so when you receive sensor data on the parent instance, it will trigger an MQTT notification (which you can hide so it won’t be seen on the control screen) to be sent out to the child instances. Likewise, for control components, you can set them up so they also trigger a MQTT message (like the kids turning on a switch) so it will send a message to the parent instance and trigger the appropriate component.
Each instance of HA will have its own configuration.yaml file with its own password and available components. So until a component comes along that does a better job, you can run everything through the MQTT server.
Have you tried this? I love the lateral thinking, but maybe the kids will just have to lift their ass to turn on the lights/media center/etc. until there’s way to do this natively. Or until I get enough sh*t about it that I have to. In any case, thanks for sharing.
A relativley easy idea is to take the Home-Assistant default home screen, remove from the html any side-bars and tabs. Leave only the components that you want to share. Host the page at the same web-server at location :8123/share.
Kids, parents, grandparents, housekeeping. They all have portable devices which should have different type of access. Different views.
This was something which was very very useful when I was running Domoticz. And something which is missed now. Don’t want to build a portal which authenticates and based on credentials shows different views while connecting to hass with the same api key.
Logging, access, access restrictions… from what I understand, kiosk mode is simply /kiosk… with the user having access to the root domain, what is stopping them from getting into the root and even changing config etc?
Agree. It is way cool to do lots of components every release, but it’s core functionality which is lagging a bit in development unfortunately. Multi-user is such a core functionality.
Kiosk is nice but not sufficient at all.