Limit WordPress session duration on shared computers

Define the expected duration and workstation type

A team may use WordPress from a reception workstation or a computer shared by several people. In this context, a long-lived session may remain available after the writer leaves. Agree with the owner on the acceptable duration of a new login, the expected behavior when the browser closes, and the logout procedure at the end of work. The setting must match actual usage, especially long periods of writing or order preparation. Scope of the example: the two-hour limit applies to all new sessions on the installation, even on a personal computer; the code does not detect shared computers.

Distinguish a duration measured from login from a timeout after inactivity. The core auth_cookie_expiration filter sets a duration associated with issued cookies. If the requirement concerns inactivity, request a mechanism that measures that inactivity and documents what it considers an action. An open page, background requests, or an editor that saves automatically may make this concept different from what the team expects.

Record which access methods use the WordPress form and which go through single sign-on or an external service. The latter may reauthenticate the user according to its own session. A duration changed in WordPress must therefore be observed end to end along the actual workflow.

Record current behavior with a test account

Prepare a test account with the permissions needed for the test. Record the time of a login without Remember Me, then that of a separate login with this option. Use separate browser profiles to avoid mixing cookies. Note the browser version and tab restoration or session retention settings. Visually closing the window does not always guarantee the cookie handling the team expects.

In the documented WordPress code, the remember option affects the duration used and cookie persistence. The project can filter this duration. Ask the maintainer whether a security plugin, internal rule, or authentication service already changes the result. A filter name in a file is a clue, but its presence alone does not establish callback priority or the final value.

Also record what a writer sees when their session expires. A request to log in again while drafting must be covered in acceptance testing, using a demonstration document. Avoid testing a short limit on real work that has not yet been saved.

Choose a policy the team can explain

One example policy is to limit all new WordPress sessions on the installation to two hours, even if the user selects the remember option. Another project may want a different duration depending on the chosen mode. Have the values and their scope approved before changing code. For particular roles, confirm how the rule identifies accounts and what should happen if their role changes.

The duration must allow enough time for normal operations. An overly short period can cause repeated logins in forms and encourage users to share a fallback account. Choose acceptance scenarios covering a short action, a long writing session, and a workflow that returns to a page after a wait. Record the expected result for each. A session policy must remain compatible with the work-saving procedure.

Define the closing of existing sessions separately if required. Changing the filter used when cookies are issued does not mean all old cookies receive a new expiration time. If immediate logout is necessary, assign its mechanism and impact in the intervention plan.

Prepare the configuration and rollback access

Identify where the project manages authentication rules. A dedicated project plugin or a must-use plugin can contain the filter. Its location must be versioned or documented and remain accessible through the team’s deployment channel. If the provider manages this policy, ask for the value and scope it can apply. Do not layer on a second filter without taking inventory of existing rules, because their order can change the result.

Keep the previous file version and expected values in the private record. Check hosting access that allows you to restore a valid file if a PHP error prevents login. Fallback access must belong to an authorized person and remain usable independently of the session used for checking. Avoid relying solely on the WordPress file editor to fix an authentication problem.

On an isolated copy, also check the time on the server and workstation used to observe expiration. Clock drift can complicate interpretation. Record the environment type and deployment number so a test performed only on staging is not attributed to production.

Apply an explicit duration on a copy

In a project that uses the standard core mechanism, the following filter provides a two-hour duration for the cookies it affects. The example applies globally to the installation and returns the same result regardless of the remember option. It illustrates an approved policy for a shared workstation, to be adapted only after defining usage. It does not measure periods of inactivity.

Place the code in the project’s configuration component or in a must-use plugin PHP file intended for this copy. Validate its syntax before loading it and confirm that no other callback subsequently replaces this value. If the project already has a rule, change its source instead of adding a parallel definition. On a network, ask the owner to confirm whether the same setting should apply to every site in the installation.

After deployment, create a new test session. A session opened before the change does not prove that the new filter was applied. Record its start time and the loaded code version. Keep the old package ready to restore if the copy no longer starts or the login workflow fails.

On a standard installation that does not already have this filter, a concrete location is wp-content/mu-plugins/atelier-session-duration.php. Place the PHP file directly in mu-plugins: a subfolder will not load automatically without a loader. If WPMU_PLUGIN_DIR has been customized, use the project’s actual directory. Under Plugins, the Must-Use section lets you identify the component. To return to the previous state, remove only this added file, or restore only the change made to the existing component; keep the other must-use plugins, which may belong to the host.

<?php
add_filter( 'auth_cookie_expiration', function ( $duration, $user_id, $remember ) {
    return 2 * HOUR_IN_SECONDS;
}, 10, 3 );

Observe both login modes through expiration

Open two test profiles, one with the remember option and one without. Log them in after the change, then perform a demonstration administration action at the start and near the expected expiration time. After the duration, reload an administration page that requires authentication and record the result. The browser may still display previously loaded content. A page that remains visually open therefore does not prove that the session is still accepted for a new request.

The core validation mechanism has behaviors related to request context, particularly for certain POST or AJAX operations. Login cookies and their storage also have their own rules. Avoid promising universal logout to the exact second based on a single test. Document the routes and modes actually observed, along with the reauthentication behavior. A security assessment requiring a strict timeout must examine these details with the maintainer.

For a form being drafted, confirm what is retained before the login prompt and how the user resumes work. Success on a dashboard page does not automatically validate the editor workflow or a business interface provided by a plugin.

Check browser closing and restoration

On the demonstration workstation, close the windows using the team’s usual procedure. Reopen the browser with the same settings as the shared workstations and request a new administration page. Record whether the browser restores its previous session. Software may retain or restore session cookies according to its features. Workstation policy and the WordPress mechanism must therefore be examined together.

Also test the handover from one person to another. The scenario must include explicit logout, signing out of the operating system, or a separate profile according to the organization. A maximum duration does not remove the risk of an open session during the period in which it remains valid. Users must have a clear action to finish their work. Check that authorized people know how to find the logout button and confirm the result with a new request.

If the workstation uses an identity manager or single sign-on, repeat the full workflow. An identity provider session may allow automatic login to WordPress again. In this case, the service owner must confirm the shared workstation policy and the means of closing the session that reauthenticates the user.

Handle earlier sessions when the plan requires it

If the owner also requests closing existing sessions, prepare a targeted operation with authorized account or administrator tools. WordPress session functions and the corresponding WP-CLI commands can be used to inventory and remove tokens within the planned scope. Check the targeted users and the impact on their work before running a destroy operation. The documentation for the selected command must match the available version.

An inventory check may expose network addresses and session information. Keep this data in the private record and limit collection to what is useful. For a user who is present, tell them to save their work and choose an agreed time. For a potentially compromised session, follow the incident schedule decided by the owner. A logout operation and a new duration policy have complementary effects.

After removal, check that an old browser must reauthenticate on a new request and that a new authorized login works with the expected duration. Keep the evidence without copying a cookie into the ticket or a shared tool.

Diagnose a duration that appears to be ignored

If a new session greatly exceeds the expected behavior, confirm deployment, the component’s presence, and other filters that may intervene. Check whether the browser actually used a new cookie and whether the workflow uses the standard core or custom authentication. A plugin may replace part of the mechanism. A user may also have been reauthenticated by single sign-on without a visible form.

If sessions end earlier than expected, compare the identity provider, browser, and security plugin rules. A configured duration does not fix an inconsistent cookie domain, a misaligned clock, or a session removed elsewhere. Compare times and contexts before changing the value. Checking a new request helps distinguish an old screen from authentication that is still accepted.

For a difference between two frontends, ask for their configuration versions and check authentication setting consistency. A policy updated on only one server can produce varying observations. Correct the deployment source before concluding that a filter does not work in WordPress.

Return to the previous policy and preserve writing work

If the copy shows a regression, restore the previous component or remove the change through the designated deployment channel. Check that WordPress starts, then create a new test login. Restoring the file affects values issued afterward. Sessions already shortened or removed may still require a new login. Prepare users for this behavior instead of restoring an old database to recover sessions.

On a live site, choose a window with the content owner. Ask users to save their work before any closure of existing sessions and check a demonstration draft after rollback. If a business application depends on a long session, have that need addressed through an approved policy with a precise scope and a review. Avoid globally extending all sessions to solve a difficulty limited to one interface.

If dashboard access is lost because of a code error, use the fallback hosting channel to restore the valid version. Keep the redacted error message and deployment identifier. The correction must target the configuration, followed by another check of the workflows that failed.

Hand over the durations and results actually observed

The final record must state the chosen value, the accounts or environments concerned, the handling of the remember option, and the workflows tested. Add session creation times and the results of new requests after waiting. If single sign-on is involved, identify its owner and the result of the test closing its own access. A written policy must be reproducible on an identically configured workstation.

The filter presented is a WordPress core feature. Implementing it requires no commercial plugin when the team already maintains a configuration component. A security or single sign-on offering may provide different session management, with limits to check in its contract. Do not confuse a duration measured from login with a commercial inactivity feature without checking its behavior.

Keep the references to the previous version and rollback method. Schedule another review when the browser, login method, or shared workstation policy changes, because these elements contribute to the end-to-end result.

The WordPress Workshop.

An acceptance test that distinguishes duration from inactivity

Choose a fictional draft, then open two browser profiles with the same test account. Log in to the first with Remember Me and the second without this option. Record the actual time of each login. Work in the first profile and leave the second inactive: the guide’s rule is based on time since login, so this difference in activity must not be interpreted as two separate policies.

As expiration approaches, save the test draft. After expiration, request a new administration page in each profile and record the response, then the editor’s resumption behavior. A screenshot of a tab opened before expiration does not validate current authentication. Do not shorten the production policy to speed up this test.

Without technical intervention, the immediately available measure is explicit logout at the end of work and a separate operating system profile for each person. The free core filter complements this practice; it detects neither a shared computer nor its user’s physical departure. Removing the rule file restores the policy applied to new logins, but does not automatically extend a session that has already been created.