Why QCUI Checks Target Eligibility Before Issuing the Handoff
Why QCUI Checks Target Eligibility Before Issuing the Handoff is a deliberate QCUI 1.0.03 behavior that protects administrator access, target-account safety, or the integrity of the one-time impersonation handoff.
Start-time checks
- Issuing identity still has
core.admin. - Shared Sessions is disabled.
- Username is present and resolves to a Joomla user.
- Target is not self, blocked, reset-required, or Super User.
- Target has
core.login.site.
Only then is a token created
The database token row and issued audit event are created after these gates pass. A denial does not create a valid frontend handoff for the rejected target.
Why this matters
Failing early keeps obviously invalid support attempts out of the frontend identity-switch path.
Do not bypass Joomla account state
Why QCUI Checks Target Eligibility Before Issuing the Handoff should be resolved through normal Joomla user/ACL administration. QCUI deliberately refuses to impersonate accounts that Joomla or QCUI currently considers unsafe/ineligible; changing database flags or handcrafting a token would remove the controls the support workflow depends on.
Do not bypass Joomla account state
Why QCUI Checks Target Eligibility Before Issuing the Handoff should be resolved through normal Joomla user/ACL administration. QCUI deliberately refuses to impersonate accounts that Joomla or QCUI currently considers unsafe/ineligible; changing database flags or handcrafting a token would remove the controls the support workflow depends on.
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.