Loading challenge...
Session Expiry & Refresh
Rotate a short-lived access token mid-flow; replaying a rotated refresh token revokes the session
What you will learn
- Automate a full token lifecycle (login → rotate → revoke) and assert each transition on #session-state[data-state]
- Keep a multi-step flow alive across a token refresh to eliminate the top source of long E2E flakiness
- Demonstrate refresh-token reuse-detection: replaying a rotated refresh triggers a 401 that revokes the session
Session Expiry & Refresh
Log in, rotate a short-lived access token before it dies, and watch reuse-detection revoke the whole session when an already-rotated refresh token is replayed
Login issues a short-lived access token (TTL ~45s) plus a refreshtoken. Rotating swaps both for a fresh pair — the old refresh becomes invalid. Replaying that already-rotated refresh trips the server's reuse-detection control and revokes the session entirely.
The status is computed server-side. Assert on #session-state[data-state], never on client-only text.
Session Lifecycle
Login → rotate → (mis)replay, while a checkout wizard stays alive across the refresh
Session state: idle
access: —
refresh: —
previous refresh: —
Checkout wizard (survives a mid-flow refresh):
Step 1 / 4: Cart
Testing Tips
Automation hints
- ✓ Token lifecycle dying mid-flow is the #1 cause of long E2E flakiness — drive
#wizard-nextacross a#sr-refreshand assert#wizard-step[data-step]still advances - ✓ Rotate before the ~45s access TTL expires: click
#sr-refresh, then confirm#session-state[data-state=active] - ✓
#sr-replayPOSTs the already-rotated refresh — the server returns 401 and flips#session-statetodata-state=revokedwith#sr-error= "reuse detected — session revoked" - ✓ Read the rotation in
#sr-tokens: after a refresh theaccess/refreshvalues change and the old one moves to "previous refresh" - ✓ Always assert via the server-driven
#session-state[data-state]attribute — never trust the client-rendered label alone
