Beta

How CMS Direct sessions work

Understand session creation, absolute lifetime, idle renewal, heartbeat, revocation and the boundary between Direct and browser proxy access.

Steps

Follow these in order.

  1. 01Open the verified WordPress originBusinessProxy verifies access and fresh MFA, then the browser exchanges a one-time grant directly on the canonical HTTPS origin.
  2. 02Distinguish the two session limitsThe idle deadline moves with protected requests. The absolute deadline is fixed and always wins.
  3. 03Launch again after expiryA Direct session is not renewed beyond its hard deadline. Start a new launch and complete MFA again when required.
  4. 04Keep Direct separate from proxy accessDirect goes to the WordPress origin without the BusinessProxy data plane. The extension proxy lease and Alias sessions are separate.

Reference

Implementation details for setup and review.

What Direct changesDirect authorizes access to protected WordPress admin paths on the verified canonical origin. It does not relay page traffic through BusinessProxy and does not sign the user into WordPress.
  • The browser extension and its proxy mode may be off for Direct access.
  • The normal WordPress login remains a separate required step.
  • Direct traffic does not consume proxy bandwidth and is not included in exit-node traffic statistics.
How a session startsAt launch, BusinessProxy checks the account, workspace membership, CMS policy, plugin readiness and a fresh passkey or MFA assertion. It creates a pending session and a one-time grant valid for 60 seconds.
  • The browser sends the grant by a top-level POST to the verified WordPress exchange URL; it is not placed in the address bar.
  • The plugin validates and consumes the grant once, creates a random local token and sets a Secure, HttpOnly, host-only cookie.
  • If the grant expires or was already consumed, launch the CMS again instead of repeating the exchange URL.
Absolute lifetime and idle timeoutThe site policy controls both limits. Defaults are 60 minutes absolute and 15 minutes idle; the supported maximum is 480 minutes. An access window may shorten the effective absolute lifetime.
Policy: 60 min absolute / 15 min idle
12:00 grant issued -> hard end 13:00
12:01 exchange -> idle end 12:16
12:10 protected request -> idle end 12:25
12:55 protected request -> idle end 13:00
13:00 session ends; it cannot be extended
  • The absolute deadline starts when BusinessProxy issues the grant and never moves.
  • Each allowed request to a protected WordPress path moves the idle deadline to now plus the configured timeout, but never beyond the absolute deadline.
  • Protected background requests such as WordPress admin AJAX also count as activity. An open tab with no requests does not.
MFA freshness is not a session timerBy default, the MFA or passkey assertion must be no more than five minutes old when a new Direct session is issued. Its freshness is checked at launch and does not shorten or extend an already active session.
Heartbeat and control-plane outagesThe plugin asynchronously reports observed activity, lifecycle events and revocation acknowledgements. This telemetry does not authorize a request and does not extend the local session.
  • An active session can continue during a short BusinessProxy outage until its local idle or absolute deadline.
  • A new session cannot be issued while the BusinessProxy backend is unavailable.
  • Refreshing readiness in the dashboard does not refresh browser authorization.
Expiry and revocationThe plugin denies protected paths and clears an invalid cookie after idle expiry, absolute expiry or a delivered revocation. The user must start a new BusinessProxy launch to continue.
  • Owners and administrators can revoke an individual session.
  • Disabling Direct or changing a security policy revokes affected sessions.
  • Changing the plugin from Enforce to Monitor or Off revokes local Direct sessions.
  • WordPress logout terminates the current local Direct session.
Direct is separate from the browser proxy leaseThe two-minute rolling browser proxy lease and CMS Direct authorization are independent mechanisms. Renewing proxy credentials never renews Direct, and Direct activity never renews the proxy lease.