Understanding the Separate Impersonated Frontend Session

Understanding the Separate Impersonated Frontend Session explains the current QCUI 1.0.03 behavior and how it affects a Super User who needs to inspect the Joomla frontend as an eligible user.

Session fork

QCUI calls Joomla session forking when it switches identities. The frontend receives a new session identity while the administrator session continues independently.

Old metadata cleanup

QCUI attempts to remove the old frontend session metadata row after forking so stale metadata for that browser-side identity is not left behind. Session-handler behavior can already remove it, so cleanup failure is intentionally non-fatal.

Why this is central

The entire support model assumes “admin here, target frontend there.” Shared Sessions are therefore refused because they undermine that separation.

Session-safety check

After working with Understanding the Separate Impersonated Frontend Session, verify the identities explicitly: the support frontend should show the expected target while active, End impersonation should make that frontend guest, and the original administrator tab should remain the authenticated Super User. Any result that collapses those identities together should be investigated before further use.

Session-safety check

After working with Understanding the Separate Impersonated Frontend Session, verify the identities explicitly: the support frontend should show the expected target while active, End impersonation should make that frontend guest, and the original administrator tab should remain the authenticated Super User. Any result that collapses those identities together should be investigated before further use.

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.