Session Expiry Dialog

SessionExpiryDialog explains why an authenticated session is ending and gives the user the action that policy currently permits. Its owner remains responsible for the signed deadline, renewal request, retry limit, and redirect after expiry.

The interactive example demonstrates idle and retry copy locally; it does not renew or sign out a real session. Absolute-limit integration is described below.

Props

Choose copy from the real deadline

Use reason="idle" when the deadline can move after confirmed user activity. Use reason="absolute" when the sign-in has reached its fixed maximum lifetime. The absolute state disables Stay signed in through canExtend={false}; do not show a control that reports success when policy cannot extend the signed token.

The countdown must come from the server-verified session expiry. Browser storage and clocks may prompt a status check, but they are not an authority for extending or replacing a signed deadline.

Renewal states

• renewalState="pending" disables the primary action and labels the work in progress.
• renewalState="error" explains that renewal was not confirmed and changes the action to Try again. Keep the real countdown running while transport retries are bounded.
• A 401 is an expired session, not a recoverable transport error. Redirect through the product's sign-in flow and preserve a validated local return path.

Do not infer expiry from a timeout, rejected fetch, or 503. Those outcomes leave the signed session deadline in force and need recoverable feedback. Do not use client activity to revive an already expired cookie or move an absolute ceiling.

Accessibility and integration

• The component uses a native modal dialog and an assertive live region because it appears on a timer rather than after a user action.
• Supply signOutHref when the product has a local session-clearing route.
• Render the countdown after client hydration when seconds are derived from Date.now(), avoiding server/client text drift.
• Keep renewal single-flight and coordinate tabs through a signed read-only status endpoint. A storage event may signal that status changed; never trust an unsigned stored expiry.

Do / Don't

• Do distinguish idle, pending, retryable failure, and absolute-limit states.
• Do disable renewal when canExtend is false.
• Don't claim an active user was inactive when the absolute limit or a network error caused the warning.
• Don't close the warning as though renewal succeeded until the server confirms a new signed deadline.