Auth without using FlowFuse

[fullmetal-fred]

Description

Hi team FlowFuse!

Congrats on the recent release and on the awesome demo of multi-user dashboards!

In light of that I have a request: could we allow an auth workflow for dashboard on standard OSS Node-Red? I love using FlowFuse, don't get me wrong, but I teach at tradeshows where I don't have a reliable internet connection. I could perhaps self-host FlowFuse and run it on prem, and I'm open to that, but I'd also just love to be able to use a simple local auth flow.

This could be basic auth...storing the username & password as a cookie and passing them via headers on every request. This could also be something more like a session token / JWT...where the user authenticates, a flow validates the auth, then sends a JWT as a cookie back to the user...then every subsequent request from that client would include additional session & user id information in the ._client object.

I'm not particularly picky how...but I do need a unique way to authenticate & keep track of a unique user. It does seem that this could be done with a dashboard-2 plugin...and I'm also open to working on that if we feel that's the right approach. But I wanted to ask first if this should be native functionality in the opinion of the maintainers.

Then again, you tell me: if I can do this with self-hosted FlowFuse, I'll look to do that for now.

Thanks!!

Have you provided an initial effort estimate for this issue?

I am no FlowFuse team member

[wazzaarr]

I agree, while I do want to support flowfuse, pay walling out this feature in particular doesn't seem right. It's so highly requested in Node-RED. Also making it only available at $125 a month, skipping the $15 a month doesn't push Node-RED users into Flowfuse.

[joepavitt]

In light of that I have a request: could we allow an auth workflow for dashboard on standard OSS Node-Red? I love using FlowFuse, don't get me wrong, but I teach at tradeshows where I don't have a reliable internet connection. I could perhaps self-host FlowFuse and run it on prem, and I'm open to that, but I'd also just love to be able to use a simple local auth flow.

@fullmetal-fred When you're teaching at the tradeshows, does that mean you're allowing access to all of your users/students to your own Dashboard?

[joepavitt]

While I do want to support flowfuse, pay walling out this feature in particular doesn't seem right. It's so highly requested in Node-RED.

@wazzaarr I'd be very interested to know more about your use case. Our current decision is based on a case that those wanting authenticated multi-user authenticated Dashboards would be a professional/industry/enterprise requirement, running with a team of users wanting access.

[fullmetal-fred]

@fullmetal-fred When you're teaching at the tradeshows, does that mean you're allowing access to all of your users/students to your own Dashboard?

@joepavitt thanks for the question! Yes, the idea is to have a "student" instance that is shared between all students which is authenticated...I use a backend to store state, credentials, etc. Each student needs to log into the dashboard, and only get data that they're supposed to get, and only get responses from the Node-RED backend that are intended for their client connection.

My alternatives at this point are to build a bespoke front end, or to use things like Appsmith to get a low-code option. I could also continue using NR and UiBuilder...but while that project is incredibly well documented, it just doesn't have the same "batteries included" feel of D2.0, and it ends up slowing me down.

[wazzaarr]

Node-RED has become so much more, due to your work on dashboard 2. Where it was really more applicable to IOT in the past, is now really opened up to being one of the best low-code web app development platforms. Fundamentally, multi user is a requirement of web app development.

[joelvandal]

I've successfully implemented basic authentication using ui-event and ui-control, allowing for single-user access where visibility of certain pages or groups depends on the login credentials. This setup is functioning well for the moment, but it has a limitation: all users see the same content. For example, when one user navigates to a different page, the change is reflected for all users.

I explored a multi-user approach utilizing socket connections and client IDs, where I stored details like username, connection timestamp, and socket ID for each connection. This method showed promise in differentiating user experiences, but I haven't had enough time to fully integrate it.

[wazzaarr]

That's great info. I've actually started using WeWeb as the front end. It works really well.

On Mon, 1 Apr 2024, 1:43 am Joel Vandal, @.***> wrote:

I've successfully implemented basic authentication using ui-event and ui-control, allowing for single-user access where visibility of certain pages or groups depends on the login credentials. This setup is functioning well for the moment, but it has a limitation: all users see the same content. For example, when one user navigates to a different page, the change is reflected for all users.

I explored a multi-user approach utilizing socket connections and client IDs, where I stored details like username, connection timestamp, and socket ID for each connection. This method showed promise in differentiating user experiences, but I haven't had enough time to fully integrate it.

— Reply to this email directly, view it on GitHub https://github.com/FlowFuse/node-red-dashboard/issues/638#issuecomment-2028778578, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4BKMVIMDIHZ2AAEBAAHTLY3AOI3AVCNFSM6AAAAABECGEFF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYG43TQNJXHA . You are receiving this because you were mentioned.Message ID: @.***>

[joepavitt]

I've actually started using WeWeb as the front end

Is that in-place of Dashboard 2.0, or supplementary to?

[wazzaarr]

In place of, Joe. Absolutely need multi user functionality. Node-RED is a very powerful middleware and has a huge place in the low code movement.

On Mon, 1 Apr 2024, 7:41 pm Joe Pavitt, @.***> wrote:

I've actually started using WeWeb as the front end

Is that in-place of Dashboard 2.0, or supplementary to?

— Reply to this email directly, view it on GitHub https://github.com/FlowFuse/node-red-dashboard/issues/638#issuecomment-2029415195, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4BKMWLSIR67DUIYZPHZ2LY3EMSFAVCNFSM6AAAAABECGEFF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRZGQYTKMJZGU . You are receiving this because you were mentioned.Message ID: @.***>

[uschmelmer]

I would say multi-user or multi-dashboard capability is an absolute need, also for the selfhosted users. Without these features i can't find any advantage of DB 2.0 compared to the original version.

Kind Regards

[mman]

Without these features i can't find any advantage of DB 2.0 compared to the original version.

Like for example that DB 2.0 is actively maintained, does not use deprecated, and unsupported, and possibly insecure Angular 1. 😉

[joepavitt]

I would say multi-user or multi-dashboard capability is an absolute need, also for the selfhosted users.

In which case, FlowFuse is available to support this use-case.

[uschmelmer]

I would say multi-user or multi-dashboard capability is an absolute need, also for the selfhosted users.

In which case, FlowFuse is available to support this use-case.

We se need for Industral Control, for example you have some machine/productionline controlpanl with three levels of access:

1. Normal Worker: Monitoring Machine Progress and simple controls like start/stop, tool change
2. Machine Operator: Changing machine settings, error clearing
3. Service: Chaning lowlevel settings, detailed error log

Same for building automation, example hotel rooms:

1. Guest Accounts: Change Light, Sound Volume
2. Advanced settings: like HVAC, Timers

Best Regards

[joepavitt]

Thanks for the details @uschmelmer - that's exactly the kind of use cases we have in mind. If you're interested in FlowFuse as a solution here, I'm happy to put you in touch with someone that can provide more details.