fix(identity): return 400 with specific reasons on registration failure#1307
Merged
Conversation
Ran npm audit fix in clients/admin and clients/dashboard (all fixes within existing semver ranges) plus an esbuild override: - react-router 7.14.1 -> 7.18.0 (turbo-stream RCE, __manifest DoS, CSRF) - vite 7.3.2 -> 7.3.5 (server.fs.deny bypass, launch-editor NTLMv2) - ws 7.5.10 -> 7.5.11 (memory-exhaustion DoS) - js-yaml 4.1.1 -> 4.2.0 (quadratic-complexity DoS) - @babel/* -> 7.29.7 (sourceMappingURL arbitrary file read) - esbuild -> 0.28.1 via overrides (dev-server file read); vite 7 pins ^0.27.0 and 0.28.1 is the only patched release, so an override avoids the breaking vite 8 / plugin-react 6 major bump Both apps: npm audit reports 0 vulnerabilities and the production build (tsc -b + vite build) passes clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Registration failures (duplicate email/username, weak password) were thrown as CustomException defaulting to HTTP 500, and the actual Identity reasons — already carried in ErrorMessages → ProblemDetails `errors` — were dropped by the clients. Users saw a misleading "500 error while registering a new user" with no indication of what to fix. Backend: throw these (and password-mismatch) as 400 BadRequest, since they are client-input errors, not server faults. Frontend: surface the ProblemDetails `errors` array in both apps. dashboard's describe() and a new shared admin describeError() now show the real reason (e.g. "Email 'x' is already taken.") instead of the bare status + generic detail. Both shapes handled (Identity flat string[]; FluentValidation map). Tests: tighten the duplicate-email and weak-password registration integration tests to assert 400 instead of just non-success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Registering a user that already exists (or with a weak password) surfaced a misleading toast:
500 error while registering a new user— a scary server-error code with no indication of what to fix.Root cause spans three layers:
CustomException, which defaults to HTTP 500. Duplicate email/username and password-policy violations are client-input errors → should be 400.CustomException.ErrorMessages, whichGlobalExceptionHandleralready exposes in the ProblemDetailserrorsextension. They just never reached the top-level message.errors[]— the dashboarddescribe()and the admin create-useronErroronly readdetail/title/message, discarding theerrorsarray, so the real reason never reached the toast.Changes
Backend —
UserRegistrationService.csHttpStatusCode.BadRequestinstead of the default 500.Frontend — both apps now surface the ProblemDetails
errorsarray:lib/list-helpers.tsdescribe()describeError()inlib/api-client.ts, wired intocreate-user-dialog.tsxstring[]and FluentValidation's field-keyed map.Tests — tightened the duplicate-email and weak-password registration integration tests to assert
400 BadRequest(previously only checked non-success).Result
The toast now reads e.g.
Email 'foo@bar.com' is already taken.Verification
dotnet test src/FSH.Starter.slnx): 0 failures (Integration 715, Identity 312, +others).tsc -bclean; ESLint clean on changed files.Docs
Per repo rule #10, this is a user-facing behavior change (registration now returns 400 + detailed reasons). A matching update to the docs repo may be warranted if it documents identity error responses.
🤖 Generated with Claude Code