Connect signup and login to the notifications service so users can verify their email and complete authentication using delivered email challenges.
Approach
Implemented local signup/activation and login-code routes, an authenticated TLS notifications adapter, English/Russian templates, and configurable Flutter backend adapters through DTO/mapper/service/model/provider boundaries. Reused local customer, verification and session stores. Added bounded HTTP outcome/latency metrics and preserved existing journey instrumentation.
Acceptance criteria
Signup queues activation email and activation verifies the account atomically.
Password login queues a pending-login-bound email code; successful verification creates a session.
Resends, expiry, invalid/used codes, duplicate resend requests and notification failures are handled and tested.
Flutter signup/login use configurable backend adapters, pending/error states, unverified-account recovery and confirmed-session route gating.
Configuration, templates, HTTP contracts, rollout and journey measurement are documented in docs/auth-notifications.md.
Backend/frontend review completed; make test, make lint-backend, both affected Flutter package analyses and formatting checks passed. Contribution committed, pushed and delivered in PR #39.
Notes
PR: #39. Branch: auth-38. Primary module: auth; secondary modules: notification templates and Flutter auth. Stacked merge order is #35 → #37 → #39; retarget dependent PRs after predecessors merge. The branch incorporates notification completion commit 4b14649 and the combined make test/make lint-backend checks passed. No PR merge performed.
Review fixed Mongo omitted-empty-target matching, automatic verification-key entropy, token-related log previews and replay of consumed codes. Generated localization outputs are now ignored/untracked and regenerated before frontend tests. Configuration requires notification credentials, TLS, templates and a provisioned public client. Queue acceptance is not inbox delivery. Initial signup/login retries are not exactly-once; a product crash before Send needs user resend, and session-response failures need a new login. Session restore/refresh, a production analytics sink and wallet/settings backend adapters remain outside this contribution. No live email or optional security scans run. Detailed validation, UX evidence, limitations and PR links are recorded in docs/implementation.md and docs/auth-notifications.md.
### Goal
Connect signup and login to the notifications service so users can verify their email and complete authentication using delivered email challenges.
### Approach
Implemented local signup/activation and login-code routes, an authenticated TLS notifications adapter, English/Russian templates, and configurable Flutter backend adapters through DTO/mapper/service/model/provider boundaries. Reused local customer, verification and session stores. Added bounded HTTP outcome/latency metrics and preserved existing journey instrumentation.
### Acceptance criteria
- [x] Signup queues activation email and activation verifies the account atomically.
- [x] Password login queues a pending-login-bound email code; successful verification creates a session.
- [x] Resends, expiry, invalid/used codes, duplicate resend requests and notification failures are handled and tested.
- [x] Flutter signup/login use configurable backend adapters, pending/error states, unverified-account recovery and confirmed-session route gating.
- [x] Configuration, templates, HTTP contracts, rollout and journey measurement are documented in docs/auth-notifications.md.
- [x] Backend/frontend review completed; make test, make lint-backend, both affected Flutter package analyses and formatting checks passed. Contribution committed, pushed and delivered in PR #39.
### Notes
PR: https://git.sendico.io/tech/sxchnge/pulls/39. Branch: auth-38. Primary module: auth; secondary modules: notification templates and Flutter auth. Stacked merge order is #35 → #37 → #39; retarget dependent PRs after predecessors merge. The branch incorporates notification completion commit 4b14649 and the combined make test/make lint-backend checks passed. No PR merge performed.
Review fixed Mongo omitted-empty-target matching, automatic verification-key entropy, token-related log previews and replay of consumed codes. Generated localization outputs are now ignored/untracked and regenerated before frontend tests. Configuration requires notification credentials, TLS, templates and a provisioned public client. Queue acceptance is not inbox delivery. Initial signup/login retries are not exactly-once; a product crash before Send needs user resend, and session-response failures need a new login. Session restore/refresh, a production analytics sink and wallet/settings backend adapters remain outside this contribution. No live email or optional security scans run. Detailed validation, UX evidence, limitations and PR links are recorded in docs/implementation.md and docs/auth-notifications.md.
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
Connect signup and login to the notifications service so users can verify their email and complete authentication using delivered email challenges.
Approach
Implemented local signup/activation and login-code routes, an authenticated TLS notifications adapter, English/Russian templates, and configurable Flutter backend adapters through DTO/mapper/service/model/provider boundaries. Reused local customer, verification and session stores. Added bounded HTTP outcome/latency metrics and preserved existing journey instrumentation.
Acceptance criteria
Notes
PR: #39. Branch: auth-38. Primary module: auth; secondary modules: notification templates and Flutter auth. Stacked merge order is #35 → #37 → #39; retarget dependent PRs after predecessors merge. The branch incorporates notification completion commit
4b14649and the combined make test/make lint-backend checks passed. No PR merge performed.Review fixed Mongo omitted-empty-target matching, automatic verification-key entropy, token-related log previews and replay of consumed codes. Generated localization outputs are now ignored/untracked and regenerated before frontend tests. Configuration requires notification credentials, TLS, templates and a provisioned public client. Queue acceptance is not inbox delivery. Initial signup/login retries are not exactly-once; a product crash before Send needs user resend, and session-response failures need a new login. Session restore/refresh, a production analytics sink and wallet/settings backend adapters remain outside this contribution. No live email or optional security scans run. Detailed validation, UX evidence, limitations and PR links are recorded in docs/implementation.md and docs/auth-notifications.md.