Gum ::: Dashboards Editor and Player




See help to know about passwords

See help to know about the shared secret (server restart needed).



Mingle Platform ::: Dashboards Help


Dashboards visualize in real-time the state of devices running inside one or more (local or remote) ExEns.
You can use them to monitor and operate (change device states) remotely.

Dashboards have 2 operation modes:
  • Design: Create and modify dashboards (add, move, resize and configure gadgets).
  • Execution: Run dashboards — gadgets reflect live device values and actuators can be operated.

Dashboards have 2 layouts:
  • Free: Each gadget is placed at an X%/Y% position with a Width%/Height% (relative to the browser window).
  • Grid: A set of cards of different sizes that can be created, moved, and resized freely.

Miscellaneous:
  • Each dashboard opens in a new browser tab; the main screen stays available.
  • Dashboards are saved on request (diskette icon in the toolbar).
  • Most UI elements show a tooltip on mouse-over.
  • Double-click works wherever it makes sense.
  • While designing, the help button (top-right of the toolbar) shows context-sensitive help.
  • For a full description refer to The_Mingle_Standard_Platform.pdf, chapter on Gum and Dashboards.
  • Click the help button again to close this panel.


Security & Authentication


Gum uses two independent security layers that can each be enabled or disabled separately:

1. API Authentication — Shared Secret (HMAC)

Controls who can connect to the Gum API at all.

  • How it works: At login the browser computes an HMAC-SHA256 signature of the request using the shared secret. The server verifies it before granting access.
  • Configuration: Set "shared_secret" in config.json (under the monitoring module). When null, API authentication is disabled and anyone who can reach the server can connect.
  • Tolerance: Signatures include a timestamp; the server rejects requests older than ±hmac_tolerance seconds (default 60) to prevent replay attacks.
  • Remember me: Stores the shared secret in the browser's localStorage so it is pre-filled on the next visit.
  • Changing the secret: Only the master user can change it, via "Generate new shared secret" (visible after login) — this creates a random secret, sets it, and shows it once so it can be copied. The change is saved to config.json; a server restart is required for it to take effect. Disabling HMAC entirely still requires editing config.json directly (set "shared_secret" to null) — there is deliberately no UI shortcut for it.
  • Localhost exception: Requests from localhost bypass HMAC and always have master access.


2. Dashboard Access Control — Passwords

Controls which dashboards each user can see and manage.

  • Master password: Grants full access — view, create, edit, clone, rename, delete all dashboards. Also allows changing the master password and the shared secret.
  • Dashboard password: One or more dashboards can share the same password. Entering it gives view/run access to those dashboards only (design is master-only).
  • No password: Dashboards with no password are always visible to any authenticated user.
  • Changing the master password: Enter the current master password in the "Current master password" field and the new one in "New master password", then click ✓.
Access rules summary:
  • Master password → access to all dashboards + all management operations.
  • Dashboard password → view/run only the matching dashboards, plus any unprotected ones.
  • Localhost → always master, no password required.