test(fe): run the session-ending scenarios in a browser - #4290
test(fe): run the session-ending scenarios in a browser#4290sea-snake wants to merge 138 commits into
Conversation
|
✅ No security or compliance issues detected. Reviewed everything up to 37e2025. Security Overview
Detected Code Changes
|
There was a problem hiding this comment.
Pull request overview
Adds a new Playwright E2E spec that exercises the “Ending a session” browser scenarios (EXIT-1, EXIT-3, EXIT-5, EXIT-6) to validate session teardown behavior when signing out in-app and when signing the whole browser out from II settings.
Changes:
- Introduces E2E coverage for sign-out persistence across reload and for silent re-auth failing when there is no session to resume.
- Verifies that “sign out this browser” from settings revokes access (detected on next delegation refresh after aging).
- Adds multi-origin checks: signing out of one app/origin doesn’t affect another, and a signed-out browser entry is reused after signing back in.
Suppressed comments (1)
src/frontend/tests/e2e-playwright/routes/authorize/app-sessions/ending-a-session.spec.ts:138
locator.count()does not wait for the list to render. If the "Sign out" buttons haven’t appeared yet,listedcan be 0 and the latertoHaveCount(listed)check becomes vacuous. Also, the "Signed out" visibility check uses the default 5s expect timeout, which can be flaky for a backend-driven sign-out.
const listed = await settings
.getByRole("button", { name: "Sign out" })
.count();
await settings.getByRole("button", { name: "Sign out" }).first().click();
await expect(settings.getByText("Signed out")).toBeVisible();
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
ea59096 to
f229a79
Compare
f229a79 to
797d383
Compare
797d383 to
4cc006d
Compare
4cc006d to
aeb6fd6
Compare
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVi99RYo2jyi2kCurgovNJ
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
…2e-ending-a-session
| test("picks an identity and continues", signInAsFirstIdentity); | ||
| }); | ||
|
|
||
| test.describe("signing the browser out from settings ends the app's access", () => { |
There was a problem hiding this comment.
Should this sign into two apps before signing the browser out? With one app this only proves that one session was revoked. EXIT-3 is meant to prove that the browser-wide action removes every app session for that browser.
The "Ending a session" scenarios of
docs/ongoing/session-test-scenarios.md— EXIT-1, EXIT-3, EXIT-5 and EXIT-6 — and the silent re-issue that has nothing left to answer from.Access that can be ended is the point of the design, so this is where it gets ended: by the app signing out, and by the identity's owner signing a whole browser out from settings.
The settings scenario is the one to read: END-5 lets an app keep working until the delegation it holds expires, so nothing shows the moment access is revoked, and it is the next mint that discovers the session is gone. The test therefore ages the delegation and asks for a replacement rather than expecting an instant answer.