fix(qr): fix 登入逾期 on get-password and blank first-open QR (#298)#304
Merged
Conversation
…open QR (#298) Two QR-login regressions reported in #298 vs the legacy WPF 5.9 client: 1. Pressing "取得密碼" (get OTP) right after a QR login immediately showed "登入逾期" and forced a re-login. The OTP flow's session- expired heuristic (OtpMissingLongPollingKey / OtpMissingSecretCode, added for #264) fired on the *first* attempt — but right after login the game-host portal session often isn't warm yet, so step 1/2 come back as a login-redirect page even though the session is valid. WPF never nuked the session here; it just toasted an error and the user retried successfully. commands/otp.rs now re-warms the portal session (the same auth.aspx cookie-priming GET get_accounts performs) and retries the OTP once before treating the failure as a genuine expiry. Only a second session-expired-looking failure clears auth, preserving the #264 behaviour for real server-side invalidation. 2. On first app open the QR area sometimes stayed blank/white with no error, recoverable only by toggling region (HK → TW). A transient cold-start network flake or a boot navigation-storm race (first loginQrStart rejected by the auth withGuard, a swallowed plain Error) left the QR empty. QrForm.vue now auto-retries loginQrStart once after a short delay when the first attempt yields no bitmap. Note: symptom 1 is a reverse-engineered network protocol that can't be exercised offline — needs live-server verification.
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
1 participant
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.
What
Fixes two QR-login regressions reported in #298 (new 6.0.1 vs old WPF 5.9):
Fix
1. Transient 登入逾期 on get-password (
src-tauri/src/commands/otp.rs)The OTP session-expired heuristic (
OtpMissingLongPollingKey/OtpMissingSecretCode, added for #264) fired on the first OTP attempt. Right after login the game-host portal session often isn't warm yet, so OTP step 1/2 come back as a login-redirect page even though the session is valid — WPF 5.9 only toasted an error and the user retried successfully, whereas the rewrite nuked the auth context on the first failure.get_otpnow, on a session-expired-looking failure, re-warms the portal session (the sameauth.aspxcookie-priming GET thatget_accountsruns) and retries the OTP once. Only a second session-expired failure clears auth — preserving the #264 behaviour for genuine server-side session invalidation.2. Blank first-open QR (
src/pages/QrForm.vue)A transient cold-start network flake, or a boot navigation-storm race where the first
loginQrStartis rejected by the auth storewithGuard(a plainError, deliberately swallowed), left the QR blank with no banner.QrFormnow auto-retriesloginQrStartonce after a short delay when the first attempt produced no bitmap; the manual Refresh button stays as the user-driven fallback.Closes #298