Can adminAuth be used to redirect different users to different Dashboard 2.0 pages?

Hi everyone,

I have a requirement for a SCADA project using Node-RED Dashboard 2.0.

I understand that adminAuth in settings.js can support multiple users, for example:

/adminAuth: {
type: "credentials",
users: [
{ username: "user_admin", password: "", permissions: "
" },
{ username: "user_design1", password: "", permissions: "" },
{ username: "user_design2", password: "", permissions: "
" },
{ username: "user_operations1", password: "", permissions: "" },
{ username: "user_operations2", password: "", permissions: "
" },
{ username: "user_it", password: "", permissions: "*" }
]
} */

My customer's requirement is:

  • There is only one URL for the application.
  • Users authenticate using adminAuth.
  • After login, each username should automatically be directed to a different Dashboard 2.0 page.

For example:

  • user_admin → Dashboard A
  • user_design1 → Dashboard B
  • user_design2 → Dashboard B
  • user_operations1 → Dashboard C
  • user_operations2 → Dashboard C
  • user_it → Dashboard D

My questions are:

  1. Is this possible using adminAuth alone?
  2. Is the authenticated username available within Dashboard 2.0 or Node-RED flows after login?
  3. If not, what would be the recommended approach for implementing this type of role-based dashboard routing while keeping a single URL?

Any guidance or examples would be greatly appreciated.

Thank you.

Do you realise that, having logged in, any user can access all pages in the dashboard?

This may be helpful: Building Multi-Tenant Dashboards | Node-RED Dashboard 2.0

Admin auth is separate to user auth. Admin auth applies to the Node-RED Editor and Admin API's, not to Dashboards, http-in/-response or UIBUILDER. The two different contexts actually use different ExpressJS web servers.

Dashboard 2 and UIBUILDER both support common HTTP authentication and user headers such as you would get from a secured proxy or applying common authentication tools to ExpressJS. This is what you would need.

I think this page may have something that is slightly misleading? The "Understanding Client Data" section talks about the use of socketId and socketIp properties without providing the background context regarding their limitations.

SocketId, for example, will change all too often. A reloaded page or a temporary disconnection (e.g. client browser goes to sleep) will change that ID. SocketIp may not always show the correct end user IP since it depends a lot on intermediate proxy settings and having proxy trust configured in Node-RED.

UIBUILDER provides a more stable client id along with browser tab id's and best attempt at user real IP. The socketId is still available.

As mentioned, both D2 and UIBUILDER both support common 3rd-party authentication headers.

This is something we keep having to remind people of. If you have a "Single Page App" (SPA) such as either of the 2 Dashboards or using UIBUILDER's uib-router library, the resulting "pages" are virtual routes and not actual, separate HTTP endpoints. As such they do not provide guaranteed security or privacy.