See the WordPress Experience a User Actually Receives
Restrict Switching to Eligible Accounts
User switching is powerful enough to require more than a visible button. Login as User limits the operator to the required site or network administrative capability and checks the target account before a switch is allowed. Accounts with the Administrator role and Multisite super administrators are blocked. Users holding manage_options, manage_network, or edit_users are also ineligible, so a highly privileged custom role does not become available merely because its label is different.
Those core capability restrictions always remain part of the policy, even when the corresponding names are removed from the editable settings. Additional capabilities can be listed to protect more accounts where your project needs a narrower support scope. This creates a useful boundary for agency and support workflows: you can inspect eligible lower-privilege accounts without turning the module into a route for assuming another administrator's identity.
Keep Support Sessions Timed and Easy to Leave
Once the switch succeeds, the module retains the original operator and the impersonated user in a signed session cookie. A Switch back link in the WordPress toolbar and a floating control on the frontend and in the dashboard keep the return path visible while you work. The default session lasts 60 minutes, and administrators can choose a limit from 5 minutes to 24 hours to match the length of a support or testing task.
The impersonation state does not persist indefinitely. It ends on logout or expiry, and a real password login in the target session clears the switching cookie rather than allowing two different authentication states to remain mixed. During impersonation, WP PowerSuite also sends no-cache headers and sets WordPress page and object-cache suppression flags. These signals help keep the session-specific view out of caches that honor them; they are not a replacement for correct cache configuration elsewhere in the hosting stack.
Keep a Focused Record of Impersonation Events
Being able to switch accounts is only half of a support workflow. Administrators also need to know when switching was used and which account was involved. Login as User keeps an audit record of events such as session start, switch-back, expiry, logout, module disable, and an invalid original operator. Entries include the event time, actor, target, request IP, and user agent, giving you context for reviewing use of the feature itself.
The settings show the latest 25 events and retain 100 entries by default, adjustable from 10 to 500. Retention is based on entry count, not a promise to keep a fixed number of days. The audit uses the server's remote address rather than X-Forwarded-For, which is important when interpreting records behind a proxy. For a broader record of supported WordPress changes, Activity Log complements this compact session history; the built-in impersonation audit is not a recording of every action taken inside the target account.
Coordinate Switching With 2FA and Login Redirects
An authorized operator using a controlled support action should not need to obtain the target user's second-factor code merely to start that permitted switch. Login as User therefore provides a narrow bypass for Two-Factor Authentication only during its own authorized impersonation AJAX action. This is not a general bypass for the target account, and it does not turn off that user's normal two-factor login requirement.
The module also identifies the switch to Redirect After Login so a destination can be resolved without treating the request as a conventional password login and applying ordinary role rules in the same way. That distinction matters on sites where users normally land in different account areas. A support switch is its own workflow, with its own eligibility checks and return controls, rather than an attempt to reuse every side effect of a normal sign-in.
Keep Temporary Access Separate From User Impersonation
Temporary Login and Login as User address different kinds of access. Temporary Login provides a separate temporary-access workflow, while Login as User allows an authorized operator already working in WordPress to become an eligible account for support. Login as User is explicitly blocked while a Temporary Login session is active, so temporary access cannot simply be extended into another user's account through this module.
This boundary also makes the intended operator model clearer. Give trusted permanent operators the required capability, limit which targets can be selected, choose a suitable duration, and use the switch-back control when the task is complete. Login as User does not provide administrator impersonation, a shareable passwordless invitation, or permanent access that survives logout. It provides a timed account-switching tool with defined limits and an audit record.
