Skip to content

fix(auth): миграция get_qr на новый Passport BFF (fixes #747)#762

Open
trudenboy wants to merge 1 commit intoAlexxIT:masterfrom
trudenboy:feat/qr-bff-migration
Open

fix(auth): миграция get_qr на новый Passport BFF (fixes #747)#762
trudenboy wants to merge 1 commit intoAlexxIT:masterfrom
trudenboy:feat/qr-bff-migration

Conversation

@trudenboy
Copy link
Copy Markdown

@trudenboy trudenboy commented Apr 15, 2026

Что делает PR

Переводит YandexSession.get_qr со старого эндпоинта /registration-validations/auth/password/submit на новый Passport BFF /pwl-yandex/api/passport/*.

Закрывает #747 (и дубль #761).

Проблема

Яндекс начал отдавать 40x вместо JSON на legacy /registration-validations/auth/password/submit, Логин через куки (mobileproxy.passport.yandex.net/1/bundle/oauth/token_by_sessionid) не затронут и продолжает работать — именно поэтому cookie-метод сейчас единственный рабочий обход в треде.

Решение

Фронтенд Passport уже сам переехал на новый BFF /pwl-yandex/api/passport/*. Этот BFF принимает те же данные, но:

  1. Ждёт page CSRF в заголовке X-CSRF-Token, а не в form-поле.
  2. Требует явные заголовки Origin / Referer.
  3. Разбит на два вызова:
    • POST /pwl-yandex/api/passport/auth/multistep_starttrack_id
    • POST /pwl-yandex/api/passport/auth/password/submit с with_code=1 → per-track csrf_token

Legacy-эндпоинт поллинга /auth/new/magic/status/ не менялся и всё так же использует per-track csrf_token из шага 3, поэтому login_qr не трогаем.

Diff в двух словах

Шаг Было (legacy) Стало (BFF)
1 GET /am?app_platform=android → page CSRF из HTML без изменений
2 POST /pwl-yandex/api/passport/auth/multistep_start (заголовок X-CSRF-Token) → track_id
3 POST /registration-validations/auth/password/submit с csrf_token + retpath + with_code=1 в form-body → track_id + per-track csrf_token POST /pwl-yandex/api/passport/auth/password/submit с заголовком X-CSRF-Token + track_id/with_code/retpath в form-body → per-track csrf_token
4 поллинг /auth/new/magic/status/ без изменений

Cookie-логин, retry/csrf-механика в request() и все остальные флоу не тронуты — миграция нужна только в get_qr.

Референс

Я выделил те же auth-флоу Яндекс Passport в отдельную async-библиотеку и пару дней назад отвалидировал эту BFF-миграцию против живого Passport в рамках параллельной задачи для Music Assistant:

Формат эндпоинтов/заголовков из этого PR совпадает с тем, что сейчас в этой библиотеке, и уже прогоняется реальными пользователями через QR-логин end-to-end.

The legacy /registration-validations/auth/password/submit endpoint has
started returning 400 Bad Request + captcha HTML for non-browser
clients, which breaks QR login for every user (see AlexxIT#747, AlexxIT#761). The
new Passport BFF accepts the same inputs but:

- expects the page CSRF in the X-CSRF-Token header (not form body)
- requires explicit Origin/Referer headers
- splits the flow into two calls: multistep_start (get track_id) then
  password/submit (get per-track csrf_token)

The legacy /auth/new/magic/status/ polling endpoint is unchanged and
still consumes the per-track csrf_token from step 3, so login_qr is
not touched.

Cookie login and the request() retry/csrf machinery are also not
touched — only get_qr needed the BFF migration.

Closes AlexxIT#747.
@trudenboy trudenboy changed the title fix(auth): migrate get_qr to new Passport BFF (fixes #747) fix(auth): миграция get_qr на новый Passport BFF (fixes #747) Apr 15, 2026
@trudenboy trudenboy marked this pull request as ready for review April 15, 2026 10:28
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