Allow a suffix on team broker client IDs so clients that generate their own client ID can connect

[robmarcer]

Description

The team broker currently requires the MQTT Client ID to be an exact string match for the username. In forge/comms/v2AuthRoutes.js:

const parts = username.split('@')
teamId = parts[1]
if (username === clientId) {
    authorized = await app.db.controllers.TeamBrokerClient.authenticateCredentials(username, password)
}

This is documented behaviour: "Please note that username must also be used for the client id to connect to the team broker", and "each username/password can only be used with a single MQTT client at a time."

The problem

A number of MQTT client libraries and low-code connectors do not give the user full control over the client ID. They accept a client ID and then append their own uniqueness suffix before connecting. Any such client cannot connect to the team broker at all, and there is no setting to relax the check. The behaviour is identical on FlowFuse Cloud and self-hosted, so there is no workaround available to a self-hosted customer either.

We have hit this with a partner who is building a Mendix based MES on top of a self-hosted FlowFuse for their end customer. Mendix's MQTT connector supports username, password and client ID, but always appends to the client ID to make it unique. They cannot use our broker as a result, and it is currently blocking their delivery.

Suggested change

Accept a client ID that is the username plus a suffix, in addition to an exact match. We already do exactly this for our own high availability instances, in authenticateNrMqttNodeUser in forge/db/controllers/TeamBrokerClient.js:

if (parsedClientId.haId) {
    clientIdValid = `${authId}:${parsedClientId.haId}` === clientId
} else {
    clientIdValid = authId === clientId
}

So the shape of a suffix-tolerant client ID already exists in the codebase for one class of client. This request is to extend something equivalent to team broker clients.

The design question this raises

The exact match is not arbitrary. The comment immediately below it says "this test is to ensure that only a fixed number of clients can connect", so it is how we hold one credential to one connection and keep the licensed MQTT client count meaningful.

Relaxing the match to allow any suffix would let a single username open several simultaneous connections, which weakens that. If we want this, the concurrency limit probably needs to move from "client ID equals username" to counting or capping active connections per username at the broker. That is the part that needs a decision rather than an implementation.

Acceptance criteria

1. A client authenticating as alice@32E4NEO5pY with a client ID of alice@32E4NEO5pY followed by a suffix connects successfully.
2. The per-team MQTT client limit is still enforced, and a single credential still cannot be used to open unlimited concurrent connections.
3. Existing clients that send an exactly matching client ID continue to work unchanged.
4. The team broker documentation is updated to describe what is now accepted.

Which customers would this be available to

Team + Enterprise Tiers (EE)

This should match wherever the team broker itself is already available, rather than introducing a different boundary.

Have you provided an initial effort estimate for this issue?

I can not provide an initial effort estimate

[robmarcer]

This was requested by - https://app-eu1.hubspot.com/contacts/26586079/record/0-2/210435269840

[hardillb]

If we want this, the concurrency limit probably needs to move from "client ID equals username" to counting or capping active connections per username at the broker. That is the part that needs a decision rather than an implementation.

We can't do this without moving to even more tighly integrating the auth code with the specific broker implementation, and it would add latency as we would need to query the broker for how many connections exist for that user on each auth request.