Your account
HOL-D102Story implementation: In progress

Review and sign out my devices

account · Proposed launch phase 1

Start from Home

Review as Registered user

User story

As a registered member, I want to review and revoke my signed-in sessions so I can stop unwanted access to my account.

Draft requirements for review · Updated 2026-10-19

What the app should do

  • Use my own Member account security; professional/org context does not create another login. Optional MFA must be satisfied when enabled.
  • List only my account’s real local sessions, identifying the current session and only device/time information actually available; do not invent location or metadata.
  • Revoke a selected other session or all other sessions with clear confirmation; use D058 for current-session sign-out and normal session expiry.
  • Verify effective access loss with direct protected requests and a second browser/session, not just a changed list. Record actual access-token and refresh-token behavior and address any remaining access window before claiming completion.
  • Handle already-ended sessions, stale lists, concurrent sign-out, failure/retry and expired current authentication. Deny cross-account revocation and forged session IDs.
  • Session removal does not delete the account/profile, cancel membership, remove professional roles or change org/staff assignments. Keep session tokens and secrets out of public data and logs.
  • The shared Sign-in & security section links existing real session inspection/revocation; settings navigation is read-only with respect to session revocation and selected Home. Provider/Data-API enforcement limits remain explicit.

What to check in the demo

Follow these steps from the role’s landing page through navigation and feature checks.

Review asStart here: Home

Begin on the free Member Home. For a local example use Sign in → Try a demo account → Alex Morgan → Open account, then choose Member in the account/workspace menu if a remembered workspace opens. This is a genuine local account; no paid access is supplied.

Navigation from sign-in

  1. 01Open the fictional Registered user account through the connected sign-in service. Seeded Home review opens directly. Real HOL staff access and protected actions require an authenticator check.
  2. 02From the account’s Home open account/workspace menu → Account security. The feature starts at Signed-in sessions; there is no separate Signed-in devices page.

Feature checks start here

Account security · Signed-in sessions

Connected in dev; full acceptance remains In progress. The real device list marks the current session. Ending an older session removes it while the current session remains; backend tests prove immediate protected Data API cutoff. Cross-browser/bulk edge review remains open.

  1. 03Wait for Signed-in sessions to load and identify the current session. Use a second dedicated browser/session with the same test account to create another entry.
  2. 04On Another session select End session, or choose Sign out other sessions. The current session should remain; verify the other session cannot continue a protected app-data request.
  3. 05Device metadata and backend Data API cutoff are separate from merely seeing a list. Cross-browser/replayed/another-account requests need controlled setup; do not describe Storage/Realtime cutoff as verified.

Backend work for this feature

Backend development authorized · Dev only

What needs to be supported

  • Expose an owner-scoped real session summary with supported honest metadata and no bearer/refresh tokens or factor secrets.
  • Revoke selected/all-other sessions only for the authenticated owner; validate requested session IDs server-side and handle already-ended/stale lists/idempotent repeat requests.
  • Define and test the effective access-loss behavior for refresh and already-issued access tokens; direct protected requests must match the UI claim. Do not mark the story complete with refresh revocation alone if protected access still works.
  • Keep organization/staff authorization checked against current trusted records independent of session-list UI. Deny cross-account revocation and preserve unrelated account data.

How to verify in dev

  1. Open two real provider sessions for one owner, revoke the other and try direct protected reads/writes and refresh from the revoked session; measure actual cutoff and verify current session behavior.
  2. Repeat an ended-session command and use an unrelated account/session ID; verify denial, honest metadata, no token leakage and unchanged saved data/access assignments.

Before this can work

  • Begin on the free Member Home. For a local example use Sign in → Try a demo account → Alex Morgan → Open account, then choose Member in the account/workspace menu if a remembered workspace opens. This is a genuine local account; no paid access is supplied.
  • Use my own verified local synthetic account and its currently assigned scope; satisfy required MFA without a preview bypass.

Connected stories