How QCUI Maintains Joomla Frontend Login State During Impersonation

How QCUI Maintains Joomla Frontend Login State During Impersonation describes a current QCUI 1.0.03 implementation detail that matters when you are validating security, session isolation, or support behavior.

Joomla identity and cookie

After switching to the target, QCUI loads that Joomla User into the site application/session and sets the joomla_user_state cookie to logged_in using Joomla cookie path/domain and HTTPS settings.

Ending

When returning the tab to guest, QCUI loads user ID 0 and clears the same user-state cookie. That keeps frontend UI code that relies on Joomla’s logged-in state consistent with the active identity.

Not a credential cookie

This does not store the target password. The real server-side identity remains the forked Joomla session.

Security boundary

The controls described for How QCUI Maintains Joomla Frontend Login State During Impersonation 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.