Ability to change error message without writing custome middleware

[with-shrey]

• node version - 14
• celebrate version - 12
• joi version (via npm ls --depth=0 | grep joi) - latest

when using app.use(errors()) middleware there is no ability to change the default message text . If i write custom middleware, there is no method to get the errors in same format as given by the middleware

[arb]

Writing a custom error handler is for this use case. This is really all the formatting going on.

Who would be the consumer of this message in this case?

[with-shrey]

@arb we are working in microservices architecture

It would be really nice to have a function that could generate this error message rather than copy pasting the code everywhere

[arb]

If the consumer of the error is another micro service, wouldn't it just be interested in the status code anyway? That message value is intended to be for human readable errors.

If the default error handler suits ALL of your needs except the value of message I would be very curious why that one value is that important.

I'm really not looking to expand the API for errors any more than I already have. It is intended to copy how hapi responds with Joi errors and no more. I made all the methods available to write your own error handler which offers this level of customization.

[ghost]

Just to weigh in on this: the included error handler works nicely but it does expose the fact that celebrate is being used by setting 'celebrate request validation failed' as a message.
It's never a good idea to expose details about your implementation to the outside world and I second the notion that it would be nice to be able to set a custom error message like 'Bad Request' or 'validation failed' through the options passed to the errors middleware.
Including isCelebrateError based logic in your own error handler seems like overkill for this purpose.

[arb]

Yeah you're right about it not being a good practice to expose that implementation detail. The errors coming back from celebrate really aren't intended for user eyes; but still. I guess I'd be willing to allow a message override option to the errors middleware.

[ghost]

Thanks for the reply! Even if users are not going to see it, someone snooping traffic might get to see it and figure out some vulnerability

[arb]

I opened a PR for this if anyone wants to take a peek. It's going to be a breaking change since I'm changing the default argument for the CelebrateError constructor.

[guicompeng]

I know that we can create our own errors format, but I believe that by default it would be good not to show the validation message detail. Maybe create an option and not show by default, something like that. I had a problem, where the regex was returned to the user. It is not good security practice for the user to have this type of information.

{
...
"message": "\"name\" with value \"test\" fails to match the required pattern: /^[0-9]+$/"
...
}