Add shared two-factor verification to login and money operations #33

Merged
tech merged 2 commits from two-factor-32 into main 2026-09-12 10:45:51 +00:00
Owner

When two-factor protection is enabled, login now stays pending and money operations wait for a matching verification approval. A reusable SXCHNGE-themed EN/RU page shows the action being confirmed, preserves transaction details, and handles invalid/expired codes, resend cooldown, attempt limits, service errors and cancellation. Account settings support verified enable/disable.

Shared auth preserves DTO → mapper → service → data model → provider → UI. Email is the initial fixture; method-aware contracts and instructions also support future authenticator/TOTP adapters without email-only controls. The dummy wallet validates one-use, purpose/quote-bound approvals and retains idempotent retries and uncertain-outcome reconciliation. Analytics distinguishes intermediate verification from completed login, settings or settlement, without collecting codes or grants.

Validation: all 147 frontend tests; formatting of all 34 changed Dart files; analysis in app, sxchnge_auth, sxchnge_wallet and sxchnge_analytics; web build with Wasm dry run; diff checks. Browser checks at 1280×720 and 390×844 covered themed layout, invalid-code recovery, keyboard entry and confirmed settings. Widget coverage includes RU at 320px/1.6× text scale and every money entry point.

Initial service code: 123456; protection defaults off and resets on reload. No real email delivery, TOTP enrollment, recovery or production backend enforcement is connected. No security scan was requested or run. UX/measurement and integration details are recorded in docs/ux/two-factor.md, docs/implementation.md and the shared auth README.

Closes #32.

When two-factor protection is enabled, login now stays pending and money operations wait for a matching verification approval. A reusable SXCHNGE-themed EN/RU page shows the action being confirmed, preserves transaction details, and handles invalid/expired codes, resend cooldown, attempt limits, service errors and cancellation. Account settings support verified enable/disable. Shared auth preserves DTO → mapper → service → data model → provider → UI. Email is the initial fixture; method-aware contracts and instructions also support future authenticator/TOTP adapters without email-only controls. The dummy wallet validates one-use, purpose/quote-bound approvals and retains idempotent retries and uncertain-outcome reconciliation. Analytics distinguishes intermediate verification from completed login, settings or settlement, without collecting codes or grants. Validation: all 147 frontend tests; formatting of all 34 changed Dart files; analysis in app, sxchnge_auth, sxchnge_wallet and sxchnge_analytics; web build with Wasm dry run; diff checks. Browser checks at 1280×720 and 390×844 covered themed layout, invalid-code recovery, keyboard entry and confirmed settings. Widget coverage includes RU at 320px/1.6× text scale and every money entry point. Initial service code: `123456`; protection defaults off and resets on reload. No real email delivery, TOTP enrollment, recovery or production backend enforcement is connected. No security scan was requested or run. UX/measurement and integration details are recorded in `docs/ux/two-factor.md`, `docs/implementation.md` and the shared auth README. Closes #32.
tech added 1 commit 2026-09-12 10:44:59 +00:00
tech self-assigned this 2026-09-12 10:45:23 +00:00
tech added this to the SXCHNGE project 2026-09-12 10:45:23 +00:00
tech added the frontend label 2026-09-12 10:45:24 +00:00
tech added 1 commit 2026-09-12 10:45:33 +00:00
tech merged commit 1e191fca42 into main 2026-09-12 10:45:51 +00:00
tech deleted branch two-factor-32 2026-09-12 10:45:51 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: tech/sxchnge#33