Login As User

Ways In

Six entry points, all gated on the same permission, all rendering only when the target can actually be impersonated.

The Confirmation Screen

• Identity check — the target's avatar, name and email, so there is no doubt which account is about to be entered.
• Optional reason — free text, recorded on the audit row and shown in the log.
• Restricted accounts are flagged, not blocked — banned, disabled, awaiting approval, rejected, awaiting email confirmation and bouncing-email accounts are all clearly labelled, and can still be entered. That is usually the point: you see exactly what a restricted member sees.
• Password re-prompt — the staff member's own password, before the switch.

While Signed In As Someone Else

• The staff bar is tinted and carries an accent line, so there is never a page where it is unclear whose account is in use.
• A persistent indicator and one-click return — "Signed in as {member}" and "Return to {yourself}", on every page.
• Log out means return. Clicking log out while impersonating ends the impersonation and leaves the staff member in their own account rather than signing them out — and does so without destroying their own remember-me record, which a plain logout would.
• The board treats you as the member in every respect: permissions, style, node visibility, unread counts and error messages are all theirs.

Safety Rails

• Administrators can never be impersonated. Hard-coded, not a permission — immunity that can be granted away is not immunity.
• Grantable immunity — a separate "Cannot be logged in as" permission for protecting moderators, VIPs or one individual without touching code.
• Password confirmation — a stolen staff session is not by itself enough to reach member accounts. The confirmation lasts 30 minutes and is spent on each switch, so every impersonation is confirmed separately.
• No nesting — you must return to yourself before entering another account.
• One session per staff member, board-wide. Starting a second closes the first and destroys that device's session, so there is never a forgotten tab quietly browsing as somebody.
• Enforced time limit — 30 minutes by default, after which the staff member is returned automatically. Lowering the setting shortens sessions already running; raising it never extends one that started under a tighter rule.
• Never issues a credential for the target — no remember-me cookie is ever minted for the impersonated account, so nothing outlives the session.
• Uninstalling terminates live sessions first, before the code that could end them goes away.

Every failure path returns the staff member

Each of these ends the session on its own and is recorded with its own outcome, rather than leaving somebody wearing an identity they cannot shed.

Audit Log

Admin CP → Logs → Users → Login as user, behind the standard "view logs" admin permission — the same gate the moderator log uses.

• One row per session with staff member, impersonated member, reason, IP, start time, duration and outcome.
• Filters — by staff member (a select, since the set is bounded), by impersonated member (an autocomplete, since it is not), by date range, and an active-only toggle. Filters are reflected in the URL, so a filtered view is linkable.
• Row detail overlay with the full record, including which footprint suppressions were in force for that specific session — snapshotted at the time, so it stays accurate even after the settings change.
• Deleted accounts still name themselves — usernames are stored on the row, so history survives the accounts it describes.
• Cross-referenced with the native admin log — each event also writes an xf_admin_log entry, and the two rows are linked.
• Retention — completed sessions are pruned daily after a configurable number of days (365 by default; 0 keeps them forever). Open sessions are never pruned, whatever their age.

Live Sessions

Admin CP → Users → Active sessions, behind its own admin permission — because ending a session is not reading a log, it terminates a peer administrator's browsing outright. Super admins pass automatically, so out of the box it behaves like a super-admin gate, with the difference that a board can delegate it.

• Who is signed in as whom right now, with reason, IP, start time, running duration and expiry.
• Force-end any session — the staff member's session is destroyed rather than handed back, the only outcome that cannot leave someone impersonating after an administrator decided they should not be.
• Automatic cleanup every 15 minutes closes sessions that hit their expiry, plus sessions nobody came back from — a closed laptop, a killed tab — after 24 hours. An active-sessions page that cries wolf is worse than no page at all.

Footprint Control

Six independent toggles controlling what the impersonated member is left with afterwards. All on by default

Suppression is scoped to the impersonated account specifically, so anything happening in the same request that concerns a different member still behaves normally — hiding one staff member's browsing never corrupts a third party's data.

Permissions

• Log in as another member — the capability itself. Drives every entry point.
• Cannot be logged in as — grantable immunity, for a user group or an individual member.
• Login as user: end active sessions — the admin permission for the live-session page and the force-end button.
• View logs — core's existing admin permission, which is what gates the audit log itself.

Under the Hood

• XenForo 2.3 native. Vanilla JavaScript throughout, no jQuery. Uses core's own overlay, autocomplete, data-list and password-confirmation components rather than reimplementing them.
• Two code event listeners and nine class extensions — no core file edits.
• Public app only. Impersonation state is loaded once per public page request and never touched again; the Admin, API and CLI apps are structurally excluded rather than excluded by a check.
• One dedicated table, indexed for the queries the Admin CP pages actually run.
• Cache-safe — session termination goes through XenForo's session storage service, so boards running cache.sessions behave identically.
• Fully phrased — every string is a phrase, and core phrases are reused for account states so they stay translated on any board.

1. Install the add-on

   In the Admin CP, navigate to Add-ons → Install/upgrade from archive (or Install from directory if you uploaded manually). Alternatively, install via CLI:

   $ php cmd.php xf:addon-install DC/LoginAsUser

2. Grant the permission

   Under Admin CP → Groups & permissions → User group permissions, grant Log in as another member to the staff groups that should have it. The "Log in as…" link appears in the staff bar for anyone who holds it.

3. Protect the accounts that need it

   Optionally grant Cannot be logged in as to any group or individual member that should be off limits. Administrators are already protected unconditionally.

4. Delegate session control

   Under Admin CP → Administrators, grant Login as user: end active sessions to the administrators who should be able to see and terminate live sessions. Super admins already have it.

5. Review the settings

   Go to Admin CP → Setup → Options → D.C Style - Login as user and confirm the maximum session length, password confirmation, log retention, and which parts of the visit are hidden from the impersonated member. The defaults are the strict ones.