Dashboard - Multi User Login System Flow Example

[meeki007]

Dashboard - Multi User Login System Flow Example

Demo - https://dashboard-muls.no-fs.com/ui/
Username=admin / Password=password
Resets changes every hour so if someone messes it up just try agin in an hour.

Requires nodes - node-red-contrib-twin-bcrypt & node-red-contrib-moment. You will need to add these nodes to your pallet.

Link to The Flow, v0.0.1

https://raw.githubusercontent.com/meeki007/Node-red_Dashboard_Multi-User-Login-System-Flow-Example/main/flow

Logging into the /ui/
Username = admin
Password = password

Features

Multiple User Accounts

• Users create their own account and you approve them. No need to fill out all the information yourself!
• Users can recover their own account. By setting up node-red-node-email and letting users get a new password; however email is not required users will just have to contact you to rest their password.

Restrict Tab access

• Just set the Tab number and access will only be granted to logged in users. If a user that is not logged in and clicks on a Restricted Tab they will be taken to the login page.

Basic User Account Control

• Users can change their password after logging in. They can also delete their account.

Administrator

• Select a currently registered user and see information on the account. Then you may edit their role (admin/user), reset their password, or delete the user from the system.
• Select a pending user and and see their supplied information. The you can add the pending user or delete them.
• Password Requirements can be changed to make passwords more or less secure by requiring letters, numbers, or characters in a submitted password to meet requirements.
  You can enable or disable email support for the user recovery of passwords.
• See the Log and control its stored length.
• Enable/Disable email support for user account recovery.
• Control the LOG length and refresh it as needed.

Issues

Security

• A user with a slow connection can get a load of the page before being redirected. BUT! because all triggers are tied to a socketid the user is unable to actually trigger a setting. It is recommended that any triggers and controls you create are tied to the socketid of the authorized user. Also a user would have to stop the page causing a 'lost' event for socket.io making them unable to control the page. upon reload he would be force redirected again.

• socketid's are deleted upon connect and lost events. So if a user somehow managed to trick the server into accepting that he is of socketid of a currently logged in user then it would delete the socketid upon connect and force them to the login page.

• ip addresses are tied to socketid's as well to be sure. Oh there are ways to spoof them but it adds another level.

• Do I think its safe for the big bad world wide web. NO! But the mdashboard version solves all these issues of leaky pages. Sure they can get a blip of a page but its not populated with the data. Because all data shown is per socketid. I'm working on that version ATM and hope to release it next weekend.

[TotallyInformation]

An interesting approach. But rather fragile. Since Socket.IO likes to change the socketid rather too easily. A network blip or a page reload causes the user to loose their logged in status.

It would be better to add a JWT to the messages rather than relying on the socketid.

This is what I'm doing with uibuilder.

There, you send your login request back to the uibuilder node (a standard helper function is provided in the front-end library). uibuilder passes that to your own back-end user authorisation function which can be anything from as simple as a manually provided list through to OAuth or other strategies.

If the user login is authorised, uibuilder automatically adds a JWT to the response message and then expects to see the JWT in EVERY MSG (in both directions) from then onwards.

The JWT is validated each time a msg is received. Something that needs improving because at the moment it only validates that the JWT is OK and that the expiry time hasn't passed. I'll be adding another editor-definable function to that process so that you can add things like IP address checks. I'll also add the ability to have additional elements in the token. Remembering that JWT's are NOT a security feature in themselves, only a standard data construct.

Anyway, sorry, realised that I'm going off into the inner ramblings of my brain thinking about what needs doing to get the security features of uibuilder fully live.

[meeki007]

@TotallyInformation

An interesting approach. But rather fragile.....It would be better to add a JWT

Agree! And that is how I handle it for my own flows. Not only do I use JWT I also encrypt the JWT payload.

I decided not to add this at the moment because having to download a ton of nodes puts off new users. I also just wanted to see if it could be done also I've been doing things the hard way by adding each user by hand. What I had was a working but not poloshed system. I created this as a stepping stone for more to come. Currently trying to bring mdashboad up to current version of dashboard.

[TotallyInformation]

@meeki007

having to download a ton of nodes puts off new users

Yes, this is why I decided to include a security feature in uibuilder itself though I generally recommend that people use an external service to do authentication. The idea being to have the simplest viable security service available out of the box. It will only be useful for a relatively small number of users/groups out-of-the-box but can then be relatively easily expanded without having to amend the node-red flows or front-end code.

Anyway, I am back making some (painfully slow) progress on the security logic and I'm hoping to have a much better security feature set in uibuilder v4.2 which will be the next feature release.