Delivered in PR #33, branch two-factor-32; awaiting merge authorization. Validation: 147 frontend tests, formatting of 34 changed Dart files, analysis in app/auth/wallet/analytics, web build with Wasm dry run, diff checks, desktop/mobile browser review and RU small-screen widget coverage all pass. No security scan requested or run.
Initial fixture code is 123456; protection defaults off and resets on reload. No real email delivery, TOTP provisioning/recovery or production backend enforcement is connected. No code, grant or target enters analytics or route URLs. Details and integration boundaries are durable in docs/ux/two-factor.md, docs/implementation.md and frontend/packages/sxchnge_auth/README.md.
### Goal
Let users manage two-factor verification and complete one reusable SXCHNGE verification page for login and money operations.
### Approach
Implemented an original, theme-driven EN/RU page with shared DTO → mapper → service → data model → provider contracts. Initial email-code fixtures use method-aware settings and challenges; authenticator instructions omit email target/resend controls. Future TOTP enrollment, method selection and recovery require backend integration. Login completion and transaction execution consume purpose/operation-bound approval; profile supports confirmed enable/disable.
### Acceptance criteria
- [x] Reusable EN/RU code screen supports cancel, invalid/expired codes, retry, unavailable service and attempt limits.
- [x] Login and top-up/exchange/payout submissions require verification when enabled, without premature success or money movement.
- [x] Profile supports loading status, confirmed enablement and verified disable.
- [x] Expired quotes and uncertain transactions retain recovery; concurrent idempotent retries debit once.
- [x] Shared architecture, privacy-safe journey measurement, tests, documentation, commit/push/PR.
### Notes
Delivered in [PR #33](https://git.sendico.io/tech/sxchnge/pulls/33), branch `two-factor-32`; awaiting merge authorization. Validation: 147 frontend tests, formatting of 34 changed Dart files, analysis in app/auth/wallet/analytics, web build with Wasm dry run, diff checks, desktop/mobile browser review and RU small-screen widget coverage all pass. No security scan requested or run.
Initial fixture code is `123456`; protection defaults off and resets on reload. No real email delivery, TOTP provisioning/recovery or production backend enforcement is connected. No code, grant or target enters analytics or route URLs. Details and integration boundaries are durable in `docs/ux/two-factor.md`, `docs/implementation.md` and `frontend/packages/sxchnge_auth/README.md`.
tech
added the frontend label 2026-09-12 10:18:14 +00:00
tech
self-assigned this 2026-09-12 10:18:14 +00:00
tech
added this to the SXCHNGE project 2026-09-12 10:18:14 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Goal
Let users manage two-factor verification and complete one reusable SXCHNGE verification page for login and money operations.
Approach
Implemented an original, theme-driven EN/RU page with shared DTO → mapper → service → data model → provider contracts. Initial email-code fixtures use method-aware settings and challenges; authenticator instructions omit email target/resend controls. Future TOTP enrollment, method selection and recovery require backend integration. Login completion and transaction execution consume purpose/operation-bound approval; profile supports confirmed enable/disable.
Acceptance criteria
Notes
Delivered in PR #33, branch
two-factor-32; awaiting merge authorization. Validation: 147 frontend tests, formatting of 34 changed Dart files, analysis in app/auth/wallet/analytics, web build with Wasm dry run, diff checks, desktop/mobile browser review and RU small-screen widget coverage all pass. No security scan requested or run.Initial fixture code is
123456; protection defaults off and resets on reload. No real email delivery, TOTP provisioning/recovery or production backend enforcement is connected. No code, grant or target enters analytics or route URLs. Details and integration boundaries are durable indocs/ux/two-factor.md,docs/implementation.mdandfrontend/packages/sxchnge_auth/README.md.two-factor-32to two-factor-32