Login failure with TOTP-enabled procedure

[tma-fritz]

Description of the bug
pytr fails to login if TOTP ("Authenticator app") was enabled in the TR app.

Reproducer with log

$ uvx --with git+https://github.com/pytr-org/pytr pytr dl_docs -s --last_days 30 --v2 export
10:08:30 Using credentials from file /home/u1000/.pytr/credentials. Phone: +4917********, PIN: ****
10:08:30 Trying to resume websession...
10:08:30 Resuming websession failed.
10:08:30 Initiating web login...
10:08:30 WAF token skipped.
Enter the code from your authenticator app: <6 digits>
10:08:36 Logged in.
Traceback (most recent call last):
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/bin/pytr", line 12, in <module>
    sys.exit(main())
             ~~~~^^
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/lib/python3.14/site-packages/pytr/main.py", line 616, in main
    else login(
         ~~~~~^
        phone_no=args.phone_no,
        ^^^^^^^^^^^^^^^^^^^^^^^
    ...<3 lines>...
        v2=args.v2,
        ^^^^^^^^^^^
    ),
    ^
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/lib/python3.14/site-packages/pytr/account.py", line 91, in login
    log.debug(get_settings(tr))
              ~~~~~~~~~~~~^^^^
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/lib/python3.14/site-packages/pytr/account.py", line 14, in get_settings
    formatted_json = json.dumps(tr.settings(), indent=2)
                                ~~~~~~~~~~~^^
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/lib/python3.14/site-packages/pytr/api.py", line 1021, in settings
    r = self._web_request("/api/v2/auth/account")
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/lib/python3.14/site-packages/pytr/api.py", line 520, in _web_request
    r.raise_for_status()
    ~~~~~~~~~~~~~~~~~~^^
  File "/home/u1000/.cache/uv/archive-v0/nuulbc0jtt9D8WTE/lib/python3.14/site-packages/requests/models.py", line 1167, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: https://api.traderepublic.com/api/v1/auth/web/session

Environment

• OS: Ubuntu
• pytr version: 0.4.11 (GIT HEAD via uvx)

Additional context
I only enabled the TOTP recently in the TR app. 2 days ago, the "v2" login with just the app worked OK.

[marcozambi]

Can confirm this independently, with some additional detail that might help narrow it down.

Setup: pytr at the pinned commit e7f3ba37167bda15c0b5501f7ddab24c8d24d37e (current master around this age), called via the Python API (pytr.account.login(waf_token="default", v2=True, store_credentials=True)), not the CLI -- but the crash is inside login() itself, so it should reproduce identically either way. Account has TOTP/authenticator enabled, same as OP.

What happens: the login itself completes fully -- phone/PIN accepted, initiate_weblogin() succeeds, the authenticator-verification POST to /api/v2/auth/web/login/processes/{id}/authenticator-verification succeeds (_raise_for_login_error doesn't raise), "Logged in." prints. The crash is entirely after that, in login()'s own trailing debug line:

log.debug(get_settings(tr))

Python evaluates get_settings(tr) eagerly regardless of the actual log level, so this always runs tr.settings() -> _web_request("/api/v2/auth/account"), which 401s.

Two layers to this, both reproduced:

1. _web_request() itself has a side effect that makes this worse: on the very first REST call after any login, _session_expires_at is still 0, so it first tries to refresh the session via a legacy endpoint, GET /api/v1/auth/web/session. That refresh call 401s too, and since it's unconditional (r.raise_for_status(), no try/except), it's actually the very first exception raised -- before you even get to the "real" /api/v2/auth/account call. Patching around just this refresh ping (skip it, proceed to the real request anyway) gets you one layer deeper...
2. ...but then the actual /api/v2/auth/account GET 401s too, in exactly the same run, using the exact same session cookies that complete_weblogin() just saved via save_websession(). So this isn't just the debug line being unlucky -- the v2-established session genuinely isn't accepted by this REST endpoint. I confirmed this happens even on a second run that resumes the previously-saved session (resume_websession() also fails calling tr.settings() internally, for the same reason) -- fully reproducible, not a one-off network blip.

Why this blocks more than just the debug line: Portfolio.compact_portfolio() (i.e. actually fetching positions/portfolio data) also calls self.settings() on its own, to look up _sec_acc_no the first time it's needed:

async def compact_portfolio(self):
    if self._sec_acc_no is None:
        self.settings()
    ...

So even a caller that doesn't care about login()'s debug output still hits this 401 as soon as it tries to fetch actual portfolio data. It's not cosmetic.

Possibly relevant: the websocket-authenticated calls (cash(), watchlist(), the portfolio subscription itself) don't go through _web_request() at all -- they authenticate via cookies sent as a raw Cookie header on the websocket handshake instead. I haven't yet confirmed whether those succeed under v2 (haven't gotten past compact_portfolio()'s settings() call to find out), but if they do, that would suggest the v2 session cookies are valid for something, and the REST-layer 401 is specific to whatever /api/v2/auth/account (or REST auth generally) expects that the authenticator-verification response isn't actually granting -- maybe an additional header, a different cookie attribute (domain/path/SameSite), or something set only by the other v2 branch (_await_weblogin_confirmation(), the app-push path) that the authenticator-verification branch skips.

Given OP's report that this only started after enabling TOTP, that lines up with my own account (TOTP enabled) also failing -- worth checking whether the app-push confirmation branch (no TOTP) is actually unaffected, if anyone can test that combination.

Happy to help test a fix against a real account if someone has a theory on what the authenticator-verification response should additionally be doing.

[tma-fritz]

FWIW, I disabled the authenticator from within the TR app, again. I can now use pytr again.