Skip to content

fix(auth): eliminate spurious TW-Regular reCAPTCHA (step-failure gate + fingerprint parity)#332

Merged
lshw54 merged 2 commits into
codefrom
fix/tw-recaptcha-gate-and-fingerprint
Jul 10, 2026
Merged

fix(auth): eliminate spurious TW-Regular reCAPTCHA (step-failure gate + fingerprint parity)#332
lshw54 merged 2 commits into
codefrom
fix/tw-recaptcha-gate-and-fingerprint

Conversation

@lshw54

@lshw54 lshw54 commented Jul 10, 2026

Copy link
Copy Markdown
Collaborator

What

TW Regular (帳密) login forced one or more Google reCAPTCHA challenges that
MapleLink never triggers on the same account/IP — the "帳號 → reCAPTCHA → 密碼 →
reCAPTCHA" flow. Root causes:

  • reCAPTCHA escalation keyed on beanfun's IsRecaptcha advisory flag instead of
    whether the step actually failed. beanfun echoes ResultData.IsRecaptcha:true
    even on a ResultCode:1 success (its own login page only reads ResultCode),
    so a successful CheckAccountType still popped a useless pre-password widget.
  • Our request fingerprint was flagged by beanfun's bot-risk engine: the
    page-fetch GETs went out without the browser client hints MapleLink sends on
    every request, so beanfun flagged the session and demanded reCAPTCHA at
    AccountLogin. Confirmed via A/B — same account/IP, MapleLink no popup, we
    popped.

Fix

  1. Gate reCAPTCHA on step failure, not the advisory flag. CheckAccountType
    now proceeds on ResultCode == 1 regardless of IsRecaptcha; AccountLogin
    only escalates when ResultCode is neither 1 nor 2. Mirrors MapleLink's
    result_code != 1 guard. Removes the useless pre-password widget.

  2. Match MapleLink's request fingerprint. Hoisted the constant browser
    headers (sec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platform,
    Accept-Language) to client-level default headers so every request —
    including the page-fetch GETs (bflogin/default.aspx, Login/Index) —
    carries them. Previously they were only on the login POSTs, so beanfun flagged
    the session on the bare GET and demanded reCAPTCHA at AccountLogin. This
    removed the remaining widget. Also switched reqwest rustls-tls
    native-tls (SChannel, as MapleLink and the original WPF client) and pinned
    http1_only.

  3. Diagnostics. Added a CheckAccountType.Verdict tracing log (parity with
    AccountLogin.Verdict) exposing result_code / is_recaptcha per step.

Verified end-to-end against live beanfun: no reCAPTCHA, logs straight into the
account list. 766 unit + 19 integration tests pass; clippy clean.

… + fingerprint parity)

TW Regular login forced reCAPTCHA(s) that MapleLink never triggers on the same
account/IP. Three independent causes:

1. Escalation keyed on the response's IsRecaptcha advisory flag while ignoring
   ResultCode, so a ResultCode:1 success popped a useless pre-password widget.
   Now gated on the step actually failing (ResultCode != 1 for CheckAccountType;
   not 1/2 for AccountLogin), matching MapleLink's guard.

2. The page-fetch GETs (bflogin/default.aspx, Login/Index) went out without
   sec-ch-ua*/Accept-Language, so beanfun's risk engine flagged the session and
   demanded reCAPTCHA at AccountLogin. Hoisted those client hints to client-level
   default headers so every request carries them, matching MapleLink. This
   eliminated the reCAPTCHA.

3. Switched reqwest from rustls-tls to native-tls (SChannel, as MapleLink/WPF)
   and pinned http1_only; added a CheckAccountType verdict log for diagnosis.

Regression tests added; verified end-to-end against live beanfun.
@lshw54 lshw54 self-assigned this Jul 10, 2026
@lshw54
lshw54 merged commit ca7a31f into code Jul 10, 2026
3 checks passed
@lshw54
lshw54 deleted the fix/tw-recaptcha-gate-and-fingerprint branch July 10, 2026 05:35
@lshw54 lshw54 linked an issue Jul 10, 2026 that may be closed by this pull request
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.

QR之類的圖標顯示錯誤

1 participant