Multiple Users/Accounts

Feature Requests
32

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.

1 Like
33

Multi user would be great. Another option could be password protecting the tabs or screens that you don’t want others to “fat finger”

34

The UI is just a tool to call the API, so any changes need to go into the backend.
Adding support for a read-only user that can’t make any changes (but can still see all state) is probably not too hard, but adding true ACL is lots of work.
All components would have to be aware of it

35

+1 to multi user to allow access to specific groups for specific users

36

true that

I am unfortunately not a developer, but exactly this is one of the first things to think about, before starting to write code.
And also unfortunately, this child has fallen in the well now :-).

So to solve this, it has to start with tiny steps, not the implementation at all.
What about creating the data model for user accounts and then start with hiding the sidebar in the main ui?
Next step could be, to remaster the API, using user account credentials.

Like I said, unfortunately no developer here, so I am not able to start planing or writing the first line of code.

Have a nice weekenda all

37

Right now, there are few options to achieve the same feature of multiple users/accounts can do. Other than the via Telegram bot, you can also use these if you prefer tablet on the wall…

  1. Floorplan - Instead of using your house floor plan, you can use this to create any kind of interface. Perhaps one interface for each users.
  2. Third party Android app such as MQTT Dash. Since it is using MQTT, you can use it to create interface to control lights/switches/etc in HA.
  3. Zanzito - Instead of dashboard on the wall, this is perfect for phone. Install this on every family members’ phone and they can control anything on HA (you program it) via voice command. Examples at My Jarvis using Zanzito (Skills Collection).
1 Like
38

I have a different use case in mind for multiple users/passwords than I’ve seen mentioned so far. I intend to add ifttt and haaska to my home setup, both of which involve exposing your HA instance to the web. As it stands now, you have to use the same API password for those services, and that is the same API password you use to access your HA (unless you trust your local network).

It’d be nice to have different users for accessing the web front end, so requests can be logged as coming from specific users. It could also be powerful to restrict API access to specific end-points / entities.

It might be possible to implement something like this with using apache or nginx as a reverse proxy.

39

I submitted a pull request that allows this (for pretty much the same reason). There were some updates requested to make it more flexible but I haven’t had a chance to look at them yet. I hope to get back to it over the next week or two.

2 Likes
40

My use case: I would like to give wife and kids the HA iOS app on their phones (for things like location triggering and push notifications), but once I do that, they have full access to the entire HA system (but really, I only want to give them access to lights and not the rest of the stuff like power and cooling to my server room / lab, custom scripts / automations that do some pretty serious things with other systems and servers I manage, etc.)

3 Likes
41

I’d love to have different access for me (admin), and other users/devices, most probably the easiest would be different passwords, or even better - user name and password. Thus the users can belong to user group with given permissions that are set in the configuration beforehand. The story short - I keep expanding the front end and bring awesome (for me) integrations and controls/automation, but not all of them are intended to be used by all family members, also the ipad that is at home should be used as a remote control only and as a notification recipient.

Additionally to user permissions, next step would be tracking of who is currently logged (looking) at the frontend so that proper automations and notifications are sent to that logged users or other user - the admin, etc.

2 Likes
42

Just a side suggestion : wouldn’t you be able to achieve most of this by putting an apache in front of Ha? If you do this and provide tailored floor plans in kiosk mode, you can restrict access to these url in .htaccess on a fairly fine grained level with as many users as you want.

43

Sure, but this is not the goal. There are several third party apps to achive parts of this.
But the main goal is, to have some kind of user management inside HA, instead of fiddling around with external workarounds :-/.

4 Likes
44

Exactly. I want to maintain single application, while at the same time to make it better. HA is great, but user permissions is a common approach that should exist in such powerful platform, not only for security reasons but also for a better usability. My wife simply hate the app on her phone because she doesnt understant and use 95% of the switches and tabs…

4 Likes
45

My use case: I share an apartment with a few more people and I want to measure individual power consumption depending on which user turned on the equipment (e.g. the electric shower). With user accounts this could be pretty straightforward. Each user would have an energy counter attached to its account.

Just keep in mind that home assistant isn’t just for wife and kids. It could be used in broader situations.

2 Likes
46

Why don’t you try MQTT Dash on wife’s phone?

Just configure it only with what she needs.

47

Reason 1: she has iPhone.
Reason 2: how to display the IP cameras with that?
Reason 3: one more app to setup/launch, support.
Reason 4: actionable notifications sent to ios home assistant app, so still she need the ios app.
Thanks for suggestion, though.

48

Same here. And,

Reason 5: The iOS app for Home Assistant gives location awareness to HA.

1 Like
49

Ugh, the problem is this is a huge undertaking to implement within homeassistant. And at a base level you are talking about things that there are currently workarounds for.

If you back up from the ‘total security’ aspect of it, I suspect simply implementing it on the frontend with multiple users would cover the use cases I see here (family, etc.). Different users being provided a different view. This would cover the app since it just displays the page but would probably need a tweak or two.

Opening the REST API to the world would be better and more easily implemented by setting a proxy with only certain api calls allowed and could have it’s own authentication. It probably wouldn’t be too hard to implement there, but would also break everything that used the REST API so would be a lot of work also.

1 Like
50

Logically, I believe a large number of users in the thread are thinking too big. There are essentially 3 things being requested,

  1. Separate Authentication
  2. Authentication Scoping
  3. User Profiles
    2&3 may be more advanced and require a reworking of the frontend infrastructure.
    However, 1 may be more achievable, would people be interested in swapping the single password system to multiple usernames and passwords, this would allow, (in theory) different devices to use a different key (username:password). By doing this, it would be possible to ‘cut’ different devices if compromised.
    Would people be interested in seeing this implemented?
8 Likes
51

I started a few PRs to enable basic child/guest/wife/husband frontend proofing.
However, it will only be security by obscurity. It can easily be bypassed if you type the correct URLs in the address bar.

How it works:

  • Create an input_text with the option mode: password enabled. A PR was started for this mode.
  • Optional: Enable in the frontend/themes section the variable display-dev:none. This will hide the Configuration link (if enabled) and the developer tools (Services, States, Events, Templates, Info) - all in the sidebar. A PR was started for this mode.
  • Multiple themes are needed if the display-dev:none is used.
  • Create some automations (better) or/and some scripts using the value of the input_text (the mode:password is optional) to hide any group you want (group.set_visibility) and the developer tools (if wanted with frontend.set_theme).
  • Using the secrets.yaml file would help a bit.

Example:

input_text:
  password:
    name: User management
    initial: Some Text
    mode: password
--
frontend:
  themes:
    admin_theme:
      primary-color: green
    restricted_theme:
      primary-color: red
      display-dev:none
--
User_1:
  trigger:
    platform: state (or template)
    entity_id: input_text.password
    to: 'password'
  action:
    - service: group.set_visibility
      entity_id: group.a
      data:
        visible: True
    - service: group.set_visibility
      entity_id: group.b
      data:
        visible: True
    - service: frontend.set_theme
      data:
        name: admin_theme

User_2:
  trigger:
    platform: state (or template)
    entity_id: input_text.password
    from: 'password'
  action:
    - service: group.set_visibility
      entity_id: group.a
      data:
        visible: True
    - service: group.set_visibility
      entity_id: group.b
      data:
        visible: False
    - service: frontend.set_theme
      data:
        name: restricted_theme
  • Another option is to create an automation where the value of the input_text should be compared with the value of anything else (state of another sensor, current time etc.). This way the “password” always changes.

ezgif-1-465f3fea35
ezgif-1-465f3fea35768×479 142 KB

9 Likes