How QCUI Uses No-Store and No-Cache Response Headers

How QCUI Uses No-Store and No-Cache Response Headers describes a current QCUI 1.0.03 implementation detail that matters when you are validating security, session isolation, or support behavior.

Headers

• Cache-Control: no-store, no-cache, must-revalidate, max-age=0
• Pragma: no-cache
• Referrer-Policy: no-referrer

Where they apply

QCUI sends these protections during administrator start, frontend consume/end, including the response carrying the raw handoff token. The dedicated handoff HTML also declares noindex,nofollow,noarchive.

Purpose

The handoff is sensitive transient authentication material. It should not be treated as cacheable navigation content or leaked as a referrer to another site.

Security boundary

The controls described for How QCUI Uses No-Store and No-Cache Response Headers 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.

Security boundary

The controls described for How QCUI Uses No-Store and No-Cache Response Headers 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.