How Atomic One-Time Token Consumption Prevents Replay

How Atomic One-Time Token Consumption Prevents Replay describes a current QCUI 1.0.03 implementation detail that matters when you are validating security, session isolation, or support behavior.

Two-part consume

  1. QCUI selects the matching hash only if used_at IS NULL and expires_at has not passed.
  2. It immediately updates that row to set used_at, again requiring used_at IS NULL.
  3. QCUI proceeds only when exactly one row was affected. A racing second request cannot successfully claim the same row.

Replay result

Refreshing/resubmitting a token after the first successful claim produces the invalid/expired/already-used path. Create a new handoff from Joomla Administrator instead.

Why this matters

A short lifetime reduces the time window; atomic claiming also limits the token to one successful consumer within that window.

Security boundary

The controls described for How Atomic One-Time Token Consumption Prevents Replay are complementary. Super-User authorization does not make a reusable token safe; a one-time token does not make Shared Sessions safe; and a visible banner does not make state-changing customer actions harmless. Preserve the complete 1.0.03 security model rather than removing individual checks for convenience.

Community Discussion

Want to compare support workflows, share practical tips, or discuss how you use this QCUI feature? Visit the QC User Impersonation Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.