Allow for socketId constraint on all widget types

[joepavitt]

Description

With the FlowFuse Authentication plugin we introduced a sidebar which allowed users to control which widget types can be constrained to a single connection/user. This is a popular feature, but not entirely bound to the concept of authentication with FlowFuse.

We've had it requested multiple times to allow for msg._client.socketId to be used in order to constrain messages to partiular connections-only. This is already possible for ui-control and ui-event nodes, but only these nodes in the pure open-source version of Dashboard 2.0

This also makes way for future auth plugins (that aren't FlowFuse) to utilise the same configuration of which widgets allow constraints

Linked Issues

• https://github.com/FlowFuse/node-red-dashboard/issues/415
• https://github.com/FlowFuse/node-red-dashboard/issues/430
• https://github.com/FlowFuse/node-red-dashboard/issues/638

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[joepavitt]

FYI @fullmetal-fred re: our recent discussions too.

[joepavitt]

Caution here to account for the fact that users may upgrade Dashboard 2.0 to get this new interface, but not update the plugin, and therefore may have UI-clash

[fullmetal-fred]

Can we perhaps do an upgrade to the plugin first which detects if the auth tab already exists and adds if dynamically if not? Or set some dashboard version limits and release a new version of the plugin at the same time?

[joepavitt]

Have put this together in a (to-be-submitted) draft PR:

It's the side panel we provide with FF Auth, but now instead, part of core. It also provides a list of "data providers", and I'll be updating the plugin schema to support:

<script type="text/javascript">
    (function () {
        RED.plugins.registerPlugin('node-red-dashboard-2-ff-auth', {
            type: 'node-red-dashboard-2',
            auth: true,
            description: 'FlowFuse User'
        })
    })()
</script>

So, anything listed as auth: true will list here, making scope for additional Dashboard 2.0 auth plugins. What d'ya think @fullmetal-fred? Would that suit your use impending plugin? The configuration re: widget types is all handled internally, so all your plugin (or any other auth plugin for that matter) need to do is append the relevant stuff to msg._client.... and Dashboard internals handle the rest depending on user configuration

[fullmetal-fred]

I think this looks really good @joepavitt. I like that we're showing the client data providers in the tab as well...it helps us trace what is appending data to msg._client. Will you provide the _client object spec as a part of this PR? We should update docs for plugins to make sure we specify what the _client object must contain for auth plugins.

[joepavitt]

Yeah I'll document accordingly.

Currently, there isn't really any formal structure to the _client object. I toyed with forcing/encouraging users to nesg their data under a specific key depending on the module, but not sure I want to enforce that, nor even can.

So was mostly going to be a bit of a free-for-all

[fullmetal-fred]

Suppose it doesn't matter since we're using socketId for managing the sessions. Free-for-all works for me.