Multiple Users/Accounts

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

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

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.

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

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

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

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.

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

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

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

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

Just configure it only with what she needs.

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.

Same here. And,

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

1 Like

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

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

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.

9 Likes

Would you mind sharing your config for your IP Camera for the Meteoblue? I cant seem to get it working but had no issues with http://www.yr.no image pulling.

I think since HA is wide use. This feature is very importance and make HA perfect. OpenHab have plan to add this too, can we study from it?

I sometimes feel like HA system makers live alone or keep control out of everyone’s hands.

Reasons I want Multi-User:

  1. Admin / Myself:
  • Full control
  1. Wife
  • Runs the iOS app for presence detection
  • Needs access to Kid control items that have been created (can lockout the TVs and internet for the kids devices)
  • Probably doesn’t want to see any of the admin screens just the core views.
  1. Kids
  • Would love to load the iOS app on their devices but they would gain access to things the wife and I don’t want them to
  • Mostly useful for presence tracking.
  1. Kiosk / Guest
  • Already covered by Kiosk option for the most part.
6 Likes

In my case I want to give HA to final end users. I will be in charge of configuring all devices / scenes / automations and that is ok.

But I also need a simple interface where users can at least update their HA password without going to edit a .yaml file (they are end users, not tech-savys as us)

At least to start with…just a single user where you can change the default HA password and recover it using an email account.

Other option I see is to delegate authorization to a third party service such as Auth0, but this requires to be online.

Thoughts / plans for this ?

Thanks,
Claudio

1 Like