How Joomla Session Forking Separates the Frontend Identity

How Joomla Session Forking Separates the Frontend Identity describes a current QCUI 1.0.03 implementation detail that matters when you are validating security, session isolation, or support behavior.

Identity switch sequence

  1. Remember the current frontend session ID.
  2. Load the target as the site application identity.
  3. Fork the Joomla session and store the target user in the new session.
  4. Mark MFA checked for this explicit Super-User support session.
  5. Refresh session metadata where enabled, remove the old metadata row when possible, and set the frontend user-state cookie.

End uses the same separation idea

Ending forks again, loads Joomla’s guest user, clears QCUI flags/MFA state, and clears the user-state cookie. The administrator session remains outside this frontend session lifecycle.

Security boundary

The controls described for How Joomla Session Forking Separates the Frontend Identity 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.