-
Notifications
You must be signed in to change notification settings - Fork 0
Management Commands
All management writes go over the socket as signed commands: the caller
proves possession of the admin token (or a realm manager key) with an
HMAC-SHA256 signature over action + timestamp + nonce + body. The secret
itself never crosses the wire; nonces are single-use (cluster-wide when
clustering is enabled) and proofs expire after 5 minutes.
const { Authorization } = require('tyo-mq');
const response = await Authorization.authManagementCommand(adminToken, {
command: '...', /* fields */
}, { host, port, protocol });The interactive CLI (npm run manager) and the web UI wrap all of these —
see Manager Tools.
| Command | Fields | Effect |
|---|---|---|
get |
— | current auth + persistence settings (tokens masked to hashes, keys masked to *_configured flags) |
set_global_auth |
enabled |
toggle auth globally |
add_realm |
realm, required?, manager_key?, key?, require_acceptance?
|
create a realm |
rename_realm |
from, to
|
rename a realm (tokens and live state follow) |
set_realm_auth |
realm, required
|
open/close a realm |
set_realm_manager_key |
realm, manager_key (empty clears) |
realm operator credential |
set_realm_key |
realm, key (empty clears), require_key?
|
consumer pre-shared key |
set_realm_acceptance |
realm, required
|
producer admission requirement |
revoke_token |
token | token_hash | realm+client_id, allow_admin?
|
revoke issued tokens (admin tokens protected unless allow_admin) |
set_persistence |
storage, storage_options
|
hot-swap the storage backend |
Settings changes persist to the loaded settings file and propagate to all cluster nodes.
| Command | Fields | Returns |
|---|---|---|
stats |
— | live realm state: producers/consumers (total + online), subscription counts, current connections |
dlq_list |
realm? |
dead-letter queue entries (all realms when omitted) |
dlq_replay |
msg_id, realm?
|
re-enqueues the message for its consumer, removes it from the DLQ, and delivers immediately if the consumer is online |
dlq_discard |
msg_id, realm?
|
drops the entry permanently |
These use their own socket events (same signing scheme):
-
AUTHORIZATION_NEXT { body: { realm? }, proof }— oldest pending request AUTHORIZATION_DECIDE { body: { request_id, approved, role?, reason? }, proof }
Library wrappers: Authorization.nextAuthorizationRequest,
decideAuthorizationRequest, nextRealmAuthorizationRequest,
decideRealmAuthorizationRequest (the Realm variants sign with a realm
manager key instead of the admin token). See Authorization Requests.
- Admin token — everything, every realm.
-
Realm manager key —
AUTHORIZATION_NEXT/AUTHORIZATION_DECIDEfor its own realm only; allAUTH_MANAGEMENT_COMMANDs are refused.
Failed commands resolve with { ok: false, code, message } (the library
wrappers reject with err.response carrying the same object):
400 bad fields · 401 invalid proof / reused nonce · 404 not found ·
409 already exists · 501 backend lacks the capability.
tyo-mq · README · Improvement Plan · Clustering Guide · Apache-2.0
Basics
Security
- Authentication and Realms
- Ephemeral Realms
- Roles and Connection Authorization
- Authorization Requests
Delivery
Routing
Operations
Reference