Why QCUI Refuses to Run with Joomla Shared Sessions Enabled

Why QCUI Refuses to Run with Joomla Shared Sessions Enabled is a deliberate QCUI 1.0.03 behavior that protects administrator access, target-account safety, or the integrity of the one-time impersonation handoff.

The risk

With Joomla Shared Sessions, site and administrator identities can be tied together. Switching the site identity could also replace or destabilize the administrator identity, creating a lockout/security risk.

QCUI behavior

Start attempts are denied and audited as denied_shared_session. Frontend consume also checks the setting and refuses before identity switching.

Supported choice

Use QCUI only with Shared Sessions disabled. If your architecture requires Shared Sessions, use another support-testing method instead of bypassing this check.

Security boundary

The controls described for Why QCUI Refuses to Run with Joomla Shared Sessions Enabled 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 Why QCUI Refuses to Run with Joomla Shared Sessions Enabled 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.