I wasn’t sure how to report this as an issue given the documentation links.
If you just type the full URL to the Things view, OH3 will list all of them even if you aren’t logged in and aren’t supposed to see settings. I haven’t tried with other views but it seems that this should be denied? In the screenshot below you can see that I am not logged in yet I can get to the Things view.
The view was accessible as http:/hostname.local/#!/settings/things/ with hostname being the hostname of my Pi.
That is a feature of the current authentication system. Currently you only need to log in to administer the system. Basic users can control devices without getting into the dangerous configuration parts.
It is an improvement over OH2 where anyone could access system management settings.
As Things may contain passwords for other services, this seems unwanted.
Passwords in thing parameters are normally hidden with **** if the binding was correctly implemented.
An issue should be opened for each binding when it is not the case.
Try this: Settings -> API Security -> Show advanced and disable “Implicit user role for unauthenticated requests” does it fix your issue?
This is the settings page, not a page that allows one to control things, though. It will list absolutely every Thing, along with their IDs, but you won’t control them directly from that page.
I think it’s working as designed, as mentioned by others here. But to file an issue on the MainUI you would file it on the openhab-webui repo and start the issue with “[MainUI]”.
You won’t want to do this. I learned the hard way that it will break all SSE subscribers not providing authentication. That means none of the UI’s will show item states. See here for reference:
Thanks for the warning.
I don’t think showing that list is “working as designed” (because it’s a settings screen), but I’ll put my openHAV instance behind a proxy with HTTP auth so that this can’t be exposed to strangers.
I do the same. You should be able to control access to that path with the proxy, but that may have unforseen issues if the UI backend needs access to display unrestricted parts.
I do not let strangers on my home network 
I didn’t know about that. I don’t use HABPanel or other UI’s only android openhab application which have authentication and looks like work normaly…
Probably HABPanel or other UI realy do not work because before OH3 you can open it without authentication which is not ok…
Bruce_Osborne: Wife or children is also stranger who can do something stupid on your setup 
Bruce_Osborne: Wife or children is also stranger who can do something stupid on your setup
If you are depending on authorization to limit access for some users you chose the wrong system a year ago. OH2 has no concept of a AAA system (authentication authorization accounting) and OH3 is just taking baby steps while trying minimize breakage for their historic users.
Agreed, access to things are not necessary for normal operation, only items are. This doesn’t seem normal at all.
Created https://github.com/openhab/openhab-core/pull/1807 to address this.
Since the equipment semantic concept has replaced the need for things and simple-mode (to an extent), I think we should be able to map things status to equipments as I personally used to use the things page to check on status and I tell that as well to other users of my system.
With this PR merged, that is not possible anymore and I will either need to give users admin permission (not gonna happen), or we will need to find a way to reflect the things status in items!
What does breaking all SEE subscribers entail, and how could it be fixed? I think I have been tempted to do so. Context: I want the rest api (get, post, put …) to only be used with logged in users.
Any recommendation / help? I do not get that restriction without the values disappearing from the screens and they do not return until I activate that option again.
Thanks.
