elysia
elysia copied to clipboard
elysiajs
Allow full validation errors in production
What is the problem this feature would solve?
I want to have my full validation errors shown in production, it's a really annoying limitation that they can't be shown and there doesn't seem to be a way to turn it off. Please let me turn it off.
What is the feature you are proposing to solve the problem?
Allow showing full validation errors in production.
What alternatives have you considered?
No response
The error details are also excluded from ElysiaTypeCustomErrorCallback in production. Therefore I can not provide a custom error in a schema in production mode.
t.String({
error: ({ value, property }) => {
console.log('property:', property, 'value:', value); // property: undefined value: undefined
}
})
the code below is an anti-pattern at best, but especially a framework should not ship environment specific logic. Ideally there are granular env variables (or config that can be supplied) to control that behavior
https://github.com/elysiajs/elysia/blob/668c7a147d14d0df0d7f7ffb273c74651463711d/src/error.ts#L498-L514
note: defaulting to obfuscating errors in prod seems fine, as long as it can be turned off
We don't include validation details on production because it can leads to security vulnerability
See https://elysiajs.com/patterns/error-handling.html#validation-detail-on-production
Just add an option to it? Let me choose what is and isn't a vulnerability, it's my app it's not yours @SaltyAom
@WillFP Elysia exclude the validation detail when process.env.NODE_ENV is set to PRODUCTION.
You can always override NODE_ENV to something else like STAGING or UAT
We don't include validation details on production because it can leads to security vulnerability
I would say as an API provider it is desirable to clearly communicate why a request fails to consumers of the API. Such an API would be publicly documented anyway, so obscuring what property validation failed on doesn't seem to make much sense to me.
I am with you that internal server errors or uncaught exceptions should never leak to the caller, but revealing validation details regarding a misuse of the API doesn't seem like a security vulnerability?
You can always override NODE_ENV to something else like STAGING or UAT
changing NODE_ENV to STAGING or UAT can have effects on other 3rd party dependencies - also or especially when using non-standard values. I would recommend reading the 12 factor apps recommendations on config, such as
Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly
Enabling the obfuscation of validation errors behind isProduction is a clear case of such grouping and we're currently seeing a case where this causes conflicts. What would speak against making this configurable through it's own env variable or config option? (which could still be enabled by default when process.env.NODE_ENV === 'production')
Intended behaviour for me is to have full validation errors in production. Having it be completely locked out without even the option to turn it off without breaking other dependencies is silly - the current option is to make my own validation error and re-add the information that I want to be shown because Elysia won't let me. It would be very easy to just add another env variable to disable the special "production" behaviour that removes errors or maybe to add an option within the Elysia instance.
I don't see why Elysia should force me to hide things when I specifically want them to be shown, if it's an ergonomic framework then why does it go out of its way to prevent me from doing this how I want them to?
My use case here is for validation errors to accompany the generated OpenAPI documentation: the schema and endpoints are already public so there is no potential for a vulnerability and it would serve as a useful aid to have the full validation errors. The lack of full validation errors in prod has even been reported as a bug in my team multiple times.
Hi @SaltyAom ! Since this is still open, can we please add the check for allowUnsafeValidationDetails at https://github.com/elysiajs/elysia/blob/78f482866446563e844d769652a5c0d46ee1507f/src/error.ts#L340 as well?
