fix(auth): don't treat a stale profile cookie as a fresh login#12
Open
mairas wants to merge 2 commits into
Open
fix(auth): don't treat a stale profile cookie as a fresh login#12mairas wants to merge 2 commits into
mairas wants to merge 2 commits into
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
jlcpcb-cli logincloses 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 retainsjlc_session_customer_codeacross 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_loginreturns 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_coderight 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).Login successful. 2 cookies saved.false positive in captured output.🤖 Generated with Claude Code