Skip to content

Release v20.58.0

Choose a tag to compare

@github-actions github-actions released this 18 Jul 13:16
4826d53

Summary

Hardens Arc's command and query endpoints against hostile, null, and malformed input. Driving every command and query endpoint with adversarial input previously produced a large number of HTTP 500 responses that returned the exception message and full stack trace to the caller. Each of those cases now degrades to a clean, correct response — a 400 for bad input, a 403 for a forbidden request, a redacted error otherwise — and internal detail is no longer leaked to clients. A new analyzer catches the most common of these mistakes at authoring time.

Added

  • ArcOptions.ExposeExceptionDetails to control whether command and query error responses include exception messages and stack traces. It defaults to enabled only in the Development environment.
  • IValidationFailure — an exception implementing it is surfaced as a command validation failure (HTTP 400) instead of a server error, so code that runs inside the command pipeline can reject a command as invalid by throwing.
  • New analyzer ARC0013 — warns when a validator rule dereferences a member of a possibly-null concept (for example RuleFor(c => c.Order.Value)), which throws at validation time instead of producing a validation error. Validate the concept first, or guard the rule with .When(...).

Security

  • Exception messages and stack traces are no longer returned to clients in command and query responses outside the Development environment. The full detail is logged server-side and the correlation id is retained, so failures can still be traced without leaking internal information.

Fixed

  • Malformed or wrong-typed command request bodies now return HTTP 400 instead of HTTP 500.
  • A command validator that throws while validating hostile or partial input now returns a validation error (HTTP 400) instead of HTTP 500.
  • A command that targets an aggregate but provides no usable event source id now returns a validation error (HTTP 400) instead of crashing with HTTP 500, with a client-safe message that does not leak the read model type.
  • A throwing command filter no longer aborts the filter chain or masks an earlier authorization result — a forbidden request now returns HTTP 403 instead of HTTP 500.
  • Observable queries no longer fail with HTTP 500 (or leak the read model type name) on an unknown sort field, and now clamp a non-positive page size to a valid page — for both MongoDB and Entity Framework Core read models.