How Signed QCTNH-to-QuantaCade Messages Are Authenticated

Signed QCTNH-to-QuantaCade messages use the shared per-installation service secret, timestamps, and nonces so the service can reject forged or stale requests.

Authentication ingredients

• Installation UUID identifies which registered site/secret applies.
• A timestamp is checked against a short acceptance window (five minutes in the current implementation).
• A unique nonce prevents the same signed message from being replayed successfully.
• The message signature is computed from the request data using the installation’s service secret and compared using timing-safe verification.

Why signatures are needed

Endpoints such as check-in/registration synchronization change operational scheduling state. TLS protects transport, while message authentication proves the caller also knows the site-specific service secret.

Failure symptoms

Incorrect server time, a damaged/mismatched service credential, or a replayed nonce can cause authentication errors even if HTTPS/DNS connectivity itself is fine. Check system clocks and re-register through Test Connection rather than editing credentials manually.

Secrets and diagnostics

When troubleshooting How Signed QCTNH-to-QuantaCade Messages Are Authenticated, prefer status codes, readiness states, hashes/“matches” indicators, and sanitized activity messages over copying raw secrets. The Joomla WebCron key and QCTNH service credential are operational credentials, not ordinary configuration text for screenshots or public discussion.

If compromise is suspected, rotate the WebCron key and resynchronize rather than trying to keep an exposed credential active.

Community Discussion

Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.