Two tokens, not one
Reading gateway state must not carry the ability to stop a vendor. A dashboard, a monitoring probe or
a read-only panel gets smsg.ops.token and can see bind state, queue depths and throughput; it cannot
disable anything.
smsg.ops.admin.token unset, or set to the same string as the read token, disables the control
verbs and they answer 404. Setting both to the same value does not “simplify” the configuration — it
switches the controls off.
Unset means disabled, not open
Unset means disabled and answering 404, not unauthenticated.
A wrong token gets the same 404 as a disabled endpoint, rather than a 401, so nothing advertises that
there is a secret here worth guessing.
The cost of that choice: a dashboard reporting 404 should be read as “check the token on both
sides” before “the gateway is down”. The gateway cannot distinguish the two cases for the caller,
and neither can the CLI, so both report the possibilities rather than guessing.
Why it is not under /secure
That prefix is authenticated with messaging credentials, which belong to customers. The data here
— bind state, queue depths, vendor names — is gateway-wide, and no customer credential should reach
it.
The endpoint lives on the management interface, port 9000 by default, away from the port that
carries messages.
Pointing the control panel’s GATEWAY_API_URL at this port yields 404s on every playground call, and
pointing GATEWAY_OPS_URL at the messaging port yields 404s on every health read. The two ports carry
different things and share no paths.
