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

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-next across a #sr-refresh and 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-replay POSTs the already-rotated refresh — the server returns 401 and flips #session-state to data-state=revoked with #sr-error= "reuse detected — session revoked"
✓ Read the rotation in #sr-tokens: after a refresh the access/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

Related Challenges

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

The status is computed server-side. Assert on #session-state[data-state], never on client-only text.

Testing Tips

Automation hints

✓ Token lifecycle dying mid-flow is the #1 cause of long E2E flakiness — drive #wizard-next across a #sr-refresh and 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-replay POSTs the already-rotated refresh — the server returns 401 and flips #session-state to data-state=revoked with #sr-error= "reuse detected — session revoked"
✓ Read the rotation in #sr-tokens: after a refresh the access/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

Session Expiry & Refresh

What you will learn

Session Expiry & Refresh

Session Lifecycle

Testing Tips

Timer

Need Help?

Related Challenges

CAPTCHA: Audio

CAPTCHA: reCAPTCHA v3

Network Intercept

Session Expiry & Refresh

What you will learn

Session Expiry & Refresh

Session Lifecycle

Testing Tips

Timer

Need Help?

Related Challenges

CAPTCHA: Audio

CAPTCHA: reCAPTCHA v3

Network Intercept