Need a tool to manage default dashboard

[warez4me]

Kiosk mode is a good idea to provide secure public access but its current implementation isn't full without an option for manage default dashboard.
It will be exellent to add same posibilities of such management as elchininet's custom sidebar has.

[NemesisRE]

I don't know what you mean by that? If you also need the functionality of custom sidebar, install it.

[warez4me]

I don't need the full functionality of the 'custom sidebar', just this option.
My scenario is to share a common external link to my HA instance with some users, but with confidence that this link can only provide limited access to a single dashboard with a hidden sidebar.
I don't have access to their devices to set kiosk dashboard as default.
This aspect is not described in your manual.
There is only information that the /lovelace dashboard cannot be used in kiosk mode.
That's why I think the kiosk-mode script should provide a tool to set any dashboard as default on any, even non-accessible device.
Exactly the way the elchininet do it in 'custom sidebar'.

I see that contributors of the newest version of kiosk-mode are NemesisRE and elchininet.
I would venture to suggest that it is possible to use part of the 'custom sidebar' code or some its ideas to make the kiosk-mode project a feature-full.

[NemesisRE]

Kiosk mode is for kiosk devices anyone with full access to the device is able to disable it. Kiosk mode is no ACL tool.

[elchininet]

@warez4me,

Neither kiosk-mode nor custom-sidebar are RBAC mechanisms. Anyone with access to the device can do whatever they want or disable what they want. kiosk-mode and custom-sidebar are not intended to "secure" your device but to offer functionalities that are not provided natively.

In the case of kiosk-mode it is intended to be used in a kiosk device (a wall-panel, an exposition device, etc) which exposes a default lovelace dashboard and tries to hide elements "inside" Home Assistant to avoid the public abandoning that dashboard accessing to certain entry-points that are not intended to be visited in this kiosk device. Its goal is not to provide kiosk-mode to different users and manage RBAC in their devices, this is something that should be provided natively and unfortunately it doesn't exist.

In the case of custom-sidebar it is intended to customize the Home Assistant sidebar by user or device basis and it has an option to set the default dashboard because Home Assistant doesn't provide a way to manage this in a centralized way, so every user needs to do it manually.

If you would like to use a single functionality of custom-sidebar or any other plugin, there is nothing wrong with installing those plugins and using their functionalities, even if you are not going to use the rest.

Each plugin serves its purpose and has its own scope but nothing stops you to install both and use specific functionalities of each one to cover your specific use case.

[warez4me]

It's a good possibility to chat with you both in one place.

I just suggested adding an option to the project that suggests itself.
After all, you must admit, it is strange that a project that for its functioning involves creating a dashboard from scratch, doesn't provide the tools to assign it as enter location.
Another project is almost entirely devoted to customization of the sidebar, but it contains an option to control the system enter location.
The maintainers of these projects are collaborating.
2+2=4.
Adding a built-in function to a script is not at all equivalent to performing this function with a third-party plugin. The amount of code loaded will almost certainly be reduced, and performance will also certainly improve.
In the current state, there are sometimes situations when dashboard is forced, but sidebar is visible for a while, which should be already hidden. Obviously, the sequence of execution of individual scripts affects here.
As for the degree of HA security, I have no illusions, the only strange thing is to see that in addition to expanding the possibilities for improving the appearance, the basic issues of managing user rights to access system elements are practically not solved.

[elchininet]

I just suggested adding an option to the project that suggests itself.
After all, you must admit, it is strange that a project that for its functioning involves creating a dashboard from scratch, doesn't provide the tools to assign it as enter location.

There are several plugins that their functionality involve that. The configuration needs to be added to a dashboard because they are intended to modify lovelace dashboards. As for example keep-texts-in-tabs, custom-more-info, header-cards or custom-attributes. None of them need to have a tool to assign the dashboard as an enter location just because it is not the intention of the plugins.

Adding a built-in function to a script is not at all equivalent to performing this function with a third-party plugin. The amount of code loaded will almost certainly be reduced, and performance will also certainly improve.

It is not relevant if that is equivalent or not. Every feature request that is out of the scope of the plugin and a workaround is provided in its place, it is logic that the workaround will not be equivalent to have the option in the plugin.

I already explained from the product perspective why it is out of the scope of the plugin, but now, from the technical side, I can explain you why it doesn't make sense such an option in the context of this plugin. kiosk-mode is intended to be applied to a lovelace dashboard. This means that you can have a configuration for one lovelace dashboard, a totally different configuration for another one and another lovelace dashboard without any configuration. This also means, that if you open a non-lovelace dashboard (as config, developer-tools, etc) kiosk-mode configuration will not be loaded and therefore will not be applied. Having a config option that is intended to be applied globally doesn't make sense in the context of kiosk-mode because only opening a non-lovelace dashboard is enough to bypass the supposed security that you want to add. On the other hand, custom-sidebar is intended to be applied globally, it doesn't matter if you are in a lovelace dashboard or not, the changes need to be applied. That is why the configuration is not added to a specific dashboard and it is provided in an external file instead.

So, as I already mentioned, if you want to have such an option that works globally, install custom-sidebar and use it. kiosk-mode is not intended for that, but anyway, technically speaking, kiosk-mode configuration is not designed to achieve something that needs to be applied globally.

[warez4me]

If the proposed perspective direction of the development of the project is unacceptable to the maintainer, then further discussion is pointless.
The only thing I want to clarify is how can someone to "open a non-lovelace dashboard (as config, developer-tools, etc)" on kiosk device if the sidebar is hidden?
And if he can do this, then what prevents him from opening the /lovelace dashboard, when the restrictions of the kiosk will not work by default and nothing will prevent him from the "accessing to certain entry-points that are not intended to be visited in this kiosk device" accidentally or intentionally?
And if I see that project is mostly about restrictions then it's only natural that I want to know the degree of reliability of these restrictions and expect the maintainer to be interested in improving ways to achieve it.
Well, if not, then no.

[NemesisRE]

Again kiosk mode is not about restricting or access control. It is for kiosk devices in a controlled environment like home, a tablet on the wall used by the family or trusted visitors. Kiosk mode is not intended to secure home assistant in any way.

[elchininet]

The only thing I want to clarify is how can someone to "open a non-lovelace dashboard (as config, developer-tools, etc)" on kiosk device if the sidebar is hidden?

Because hiding the sidebar is an option of kiosk-mode, showing it or hiding it is up to the user. But on top of that, hiding the sidebar doesn't stop one to open directly any non-lovelace dashboard. As it has been mentioned already, if someone has access to the device they can do what they want, there is no security measure in place.

And if he can do this, then what prevents him from opening the /lovelace dashboard, when the restrictions of the kiosk will not work by default and nothing will prevent him from the "accessing to certain entry-points that are not intended to be visited in this kiosk device" accidentally or intentionally?

Nothing impedes the user to do that. Again, there is no restrictions with this plugin, it does not implement RBAC. Users can open dashboards through the URL or through a JavaScript command or they can even disable kiosk-mode entirely adding a parameter to the URL. kiosk-mode does not have any security measure in place. If you want to avoid opening the URL or executing commands you should do it by other means with something with access to the device (Fully Kiosk on Android devices, for example)

And if I see that project is mostly about restrictions then it's only natural that I want to know the degree of reliability of these restrictions and expect the maintainer to be interested in improving ways to achieve it.

The project has been always to hide the sidebar and the header in a kiosk device to save space, the rest of the options are intended to avoid your kids, your spouse, your friends, etc, clicking on something that it is not intended to be clicked by them. This is not about security or RBAC restrictions and it will never be.

But anyway, I already explained that the project, by design, has a configuration per lovelace dashboard to modify the elements in that lovelace dashboard. The plugin is not designed to configure something globally. I don't know if you got it already but it is impossible to configure something in the configuration of a lovelace dashboard and pretend that this is taking into account in another dashboard or in a non-lovelace dashboard.