Skip to content

fix(auth): don't treat a stale profile cookie as a fresh login#12

Open
mairas wants to merge 2 commits into
mainfrom
fix/login-detect-via-auth-cookie
Open

fix(auth): don't treat a stale profile cookie as a fresh login#12
mairas wants to merge 2 commits into
mainfrom
fix/login-detect-via-auth-cookie

Conversation

@mairas

@mairas mairas commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Why

jlcpcb-cli login closes the browser window immediately and reports success without a real login, leaving the account unauthenticated — subsequent API calls 401.

Root cause: login() uses a persistent Chrome profile that retains jlc_session_customer_code across runs, and it deliberately rewrites session cookies to a far-future expiry so they survive restarts. On the next login the cookie is therefore already present before the user authenticates, so the cookie-based detection in _wait_for_login returns on its first poll and the window closes. When the server has since invalidated that session (logout, rotation, expiry), the lingering client-side cookie still reads as "logged in" but every real request 401s.

What

Clear jlc_session_customer_code right after launching the context, before navigating. A still-valid session simply re-issues it on the navigation (immediate, correct success); a dead one now forces a genuine login instead of a false positive.

The regression test fakes the Playwright chain, seeds the profile with a stale auth cookie, and asserts it is gone by the time login detection runs — reproducing the bug (test fails without the fix) and locking in the guard.

Note on scope

This branch also carries ceca456 ("detect login via session cookie, not landing URL"), the June cookie-based detection switch that was never pushed or merged — it is the code currently running via the editable install. Both commits are the same topic (reliable login detection), so they land together here.

Verification

  • pytest — 37 passed (12 prior auth tests, the new regression, plus the rest).
  • New test fails against the pre-fix code with the literal Login successful. 2 cookies saved. false positive in captured output.

🤖 Generated with Claude Code

mairas and others added 2 commits June 17, 2026 15:35
The post-login redirect does not reliably land on /user-center/orders,
so the strict URL-prefix check timed out after 5 minutes even when the
user had successfully authenticated. Detect login by polling for the
jlc_session_customer_code cookie instead, which is set only after a
successful login and is independent of where the redirect lands.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The persistent Chrome profile keeps jlc_session_customer_code across runs,
and login() rewrites session cookies to a far-future expiry so they never
age out client-side. On the next login the cookie is therefore already
present before the user authenticates, so the cookie-based detection returns
immediately and the browser window closes without a real login. When the
server has since invalidated that session, every subsequent API call 401s.

Clear the auth cookie right after launching the context, before navigating.
A still-valid session re-issues it on the navigation (immediate, correct
success); a dead one forces a genuine login. Regression test fakes the
Playwright chain and asserts the pre-seeded cookie is gone by the time
login detection runs.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant