Prevent opening a dashboard page

[Laurent]

As part of a user selection process on the dashboard, I would like to prevent the opening of one of its pages.
It seems possible with the UI_control node (I send in this node: {"tabs": {"disable": ["RAPPELS"]}}) but it seems to work only inside the same session.
Indeed if I click on the link of the history of my browser (Chromium) or if I enter its address http: // localhost: 1880 / ui / #! / 6 (therefore without the socketid) in the url bar , in both cases the page is displayed when it is supposed to be "disable".

I searched the forum and did a lot of testing and test the three node options, but I keep coming back to the same result.
Does anyone have a solution or could they help me direct my research?

[TotallyInformation]

Not that familiar with this part of the internals. But you need to remember that Dashboard is a single-page app. So even disabling a tab (think of Dashboard "pages" as tabs because they are not separate pages, they are all part of a single web page) is not any kind of security. A determined user could most likely access the data I would imagine.

I think that, to do what you want, you could set the CSS for the outer element of the tab to "hidden". Most likely you would need to use a ui_template node to provide some custom code to dynamically check a value?

[Laurent]

Totallyinformation ... totally prompt!
Thank you for your reply !
I will try this afternoon by replacing "disable" by "hide" and if that does not work I will start on the Template node, but to be honest I am not comfortable with this one because I have no notion of programming, hardly am I able to create a html end of page in an editor ...
Thank you again, I will keep you posted on my progress.
Laurent

[TotallyInformation]

@Laurent

to be honest I am not comfortable with this one because I have no notion of programming

Then I'm afraid that you will either be learning or you need to take a different path.

Without knowing more about why you are trying to hide things from the user and what that might be, it is not really possible to give more focussed information.

[Laurent]

Yes indeed, the object is to learn.
Regarding the objective of this approach: I give access to the dashboard to my son and my daughter by asking them to identify themselves at the start.
Then they should have access to content that is reserved for them. Thus, my son should not have access to his sister's content and his sister should not have access to his brother's content.
These contents will be text, images and videos(?) displayed with dashboard nodes.
I know how to manage the first part (access) from a form node and a switch node but it's after that it becomes more difficult for me.
Following your return, I wonder if I shouldn't just hide the groups, and not disable pages.
But if my son enters the page url in the chrome bar, ie if there is a change in socketid, will he view the groups reserved for his sister? The answer to this question already scares me !!!!

[TotallyInformation]

@Laurent

But if my son enters the page url in the chrome bar, ie if there is a change in socketid, will he view the groups reserved for his sister?

Yup. I may be wrong but I don't think there is any direct way to stop that. However, since you've identify your actual requirements now, I can make a couple of possible suggestions.

1. Run >1 instance of Node-RED. Each with their own Dashboard.

   This is by far the easiest approach. However, it does require more device resources so if you are constrained to a low-power Pi, you may need to take extra care what else is running on it.

2. Switch to uibuilder.

   This has a rather steeper learning curve but is one to consider if part of your aim is to learn. It will certainly require more programming. However, uibuilder deliberately gives you a lot more flexibility in return for your sacrifice.

   Unfortunately, the new v3 build is still in development though I'm trying to find time to merge back to master so that I can release it. v3 has a partially complete security infrastructure designed to make simple authentication and authorisation processes as easy as possible. It might already be enough for your use though.

   Even without that, it isn't so very hard to build something using v2 that would stand up to your use case as long as your children haven't been honing their hacking skills!

[Laurent]

@TotallyInformation

Yup. I may be wrong but I don't think there is any direct way to stop that. However, since you've identify your actual requirements now, I can make a couple of possible suggestions.

1. Run >1 instance of Node-RED. Each with their own Dashboard.This is by far the easiest approach. However, it does require more device resources so if you are constrained to a low-power Pi, you may need to take extra care what else is running on it.
2. Switch to uibuilder.This has a rather steeper learning curve but is one to consider if part of your aim is to learn. It will certainly require more programming. However, uibuilder deliberately gives you a lot more flexibility in return for your sacrifice.Unfortunately, the new v3 build is still in development though I'm trying to find time to merge back to master so that I can release it. v3 has a partially complete security infrastructure designed to make simple authentication and authorisation processes as easy as possible. It might already be enough for your use though.Even without that, it isn't so very hard to build something using v2 that would stand up to your use case as long as your children haven't been honing their hacking skills!

Ok I'm going on V2 which in my opinion already does a lot more things than I am capable of using.
And if while waiting for V3 my children become too good at hacking ... I will exchange them for new ones who have less skills !!

[Laurent]

Before that, I will have to understand how to run more instances of nodered

[TotallyInformation]

Good choice

@Laurent

Before that, I will have to understand how to run more instances of nodered

As always, there is choice.

Personally, I always install Node-RED locally rather than the default global install. There are various reasons for that. But in the end, it is mainly convenience for me. I know where everything is and it is all together. It also lets me run different versions of Node-RED in parallel which can be useful for testing and for migration from 1 version to another.

I have an alternate installer on my GitHub which you can look at for inspiration. The advantage of that is that it gives you a simple way to start each installed instance using npm start. It also makes sure everything is where it is needed. There is even a template systemd startup file should you want to run your instances on startup on a Linux device.

But you can also run multiple versions from a "standard" global install too. You just need a different command with a separate userDir folder.

[Laurent]

@TotallyInformation

As always, there is choice.

Personally, I always install Node-RED locally rather than the default global install. There are various reasons for that. But in the end, it is mainly convenience for me. I know where everything is and it is all together. It also lets me run different versions of Node-RED in parallel which can be useful for testing and for migration from 1 version to another.

I have an alternate installer on my GitHub which you can look at for inspiration. The advantage of that is that it gives you a simple way to start each installed instance using npm start . It also makes sure everything is where it is needed. There is even a template systemd startup file should you want to run your instances on startup on a Linux device.

But you can also run multiple versions from a "standard" global install too. You just need a different command with a separate userDir folder.

My English is so bad that I am afraid I did not understand your previous message. : If I am using uibuilder, do I need multiple nodered instances or not? (I would prefer to have only one instance on my pi).

[TotallyInformation]

No, with uibuilder, you only need 1 instance.

[Laurent]

Ok, so I confirm, I'm going on uibuilder!
Thank you for this advice, I will keep you posted on my progress.
Laurent

[hugobox]

Hi @Laurent!
A bit late to the party, but if you decide to go with Dashboard instead of ui-builder, there's a trick to getting multiple users see only the content intended for them. It lies in having all the pages in the same ui-template and having a custom password system, see an example here: Three different Dashboard users