How QCUI Enforces Joomla Super User Authorization

How QCUI Enforces Joomla Super User Authorization describes a current QCUI 1.0.03 implementation detail that matters when you are validating security, session isolation, or support behavior.

Joomla-native authorization

QCUI defines Super User by asking Joomla whether the identity authorizes core.admin. It does not rely only on a hard-coded group ID or username.

Where the check applies

• Before showing the administrator launcher.
• When the start POST is received.
• Again at frontend consume time for the issuing administrator stored with the token.

Why repeated checks matter

Permissions can change between page render, token issuance, and token consumption. Rechecking prevents a stale page or already-issued token from becoming a permanent privilege grant.

Security boundary

The controls described for How QCUI Enforces Joomla Super User Authorization 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 Enforces Joomla Super User Authorization 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.