"Run as" broken + "Could not find default user admin" is logged
Closed this issue · 6 comments
Describe the bug
I have a very strange situation with one of my Lovelace instances. The instance in question is "Run as" the Guest user since it is used by guests. They should not be able to control every entity. The setup has been working with 3.x before.
First off, when the adapter starts it logs
Could not find default user Administrator - Using admin - Please update your configuration.
How should I update my configuration? It also seems like "admin" exists:
Despite the instance is running as the "Guest" user users can control entities they should not be able to control.
E.g. the entity in question is owned by me and the Administrators group and "others" cannot write the state:
Yet when I switch the toggle associated with the entity, the state changes.
It's probably a good idea to
- Let the admin select the "Run as" user by name
- ...but write the user ID to the adapter config
- ...and later check
defaultUserObjectbased on the ID instead of the name
The issue in my case is that the guest user ID has the Guest user name. When selecting Guest on the UI, defaultUser: 'guest' is written to the adapter config but later when checking for the defaultUserObject the user name Guest is compared to the saved user ID guest.
Once I patched the config to defaultUser: "Guest" permissions are applied correctly.
Another important aspect if the configured default user cannot be found: instead of moving on with the adapter initialization and essentially removing security (quote: "all users will be able to read everything in this case.") I'd prefer if the adapter instance would stop. I was running with no security for a couple of weeks before noticing the logged warning yesterday.
The issue in my case is that the
guestuser ID has theGuestuser name. When selectingGueston the UI,defaultUser: 'guest'
So this is wrong then. Hm. It seems what ever is stored as user comes from a undocumented admin function... hmpf... :-/
Your PR definitively won't work for cases where username and userid are different and a user enables authorization. The translation from name to id needs to stay as it was...
Probably the adapter should augment the defaultUser to full ID and use it as ID. I honestly did not see that before.
Sorry for me being a bit grumpy last night. Foremost, thanks for your report and the work you put into fixing it.
You are perfectly right, the adapter should not switch to admin if he does not find the configured user.
The misconception in the adapter was, that the defaultUser was supplied to the function getUserIDFromName. Not 100% sure why it was that way. Probably because I did not get that the frontend stores the last part of the user ID instead of the name. (I did not write that part and don't know about the fillUsers function it uses to fill the select options).
So I did change the adapter, so that config.defaultUser is augmented to be the full ID once (that was not necessary in older js-controller versions, another reason for the misconception emerging) and uses that if auth is disabled (or in the cases where no username is available).
That being said, the getUserIDFromName function is required in case authentication is enabled. In that case, we don't already have the ID, but the user supplies the username during login, and we need to figure out the ID from that. So the function needs to stay basically as it was.
You are welcome to test my last commits. I'll try to get a testing release ready, but for some reason I do not yet understand, two tests are currently failing (so the release process won't launch).