After a few days of using this package, I started looking into error handling and while it's great that provideErrorExtensions gives us a window into the error returned by the REST route, the documentation also warns that it can leak unintentionally leak information.
Is there any way, short of custom resolvers, for us to format the error message in a way that would be useful for the API consumer, but avoid leaking information that we don't want to leak? For example, it's useful to have the HTTP status code and the message, but maybe not so much information about the REST call being made, e.g. its url, params, etc.
I would also be willing to submit a PR for something like this if there's interest, and if a maintainer can review/merge/release.
Hi, and thank you for this wonderful library!
After a few days of using this package, I started looking into error handling and while it's great that
provideErrorExtensionsgives us a window into the error returned by the REST route, the documentation also warns that it can leak unintentionally leak information.Is there any way, short of custom resolvers, for us to format the error message in a way that would be useful for the API consumer, but avoid leaking information that we don't want to leak? For example, it's useful to have the HTTP status code and the message, but maybe not so much information about the REST call being made, e.g. its url, params, etc.
I would also be willing to submit a PR for something like this if there's interest, and if a maintainer can review/merge/release.
Thanks again!