servant
servant copied to clipboard
Provide option to disable aeson decoding error messages
When sending an invalid json payload, the backend sends this message back:
Error in $: When parsing the record Person of type Lib.Person the key name was not present.
This exposes server internals, which I find is weird to have as default behaviour.
To workaround this, someone suggested this as a solution, which is to use Lenient in my routes:
ReqBody' '[Lenient] '[JSON] a
And then within my handler, I'd take in the following parameter:
Either String a
While this works, it looks really ugly to have to mark every route with Lenient, and every handler with Either String a.
Of course, I could always write a convenience function & type to wrap over it, but is there a better solution to this?
@qwbarch You have a good point, in that it's not great to expose server internals like this as a default behaviour. I think there is a "deeper" problem, in that we don't have an explicit support of "development" and "production" environment settings to which libraries abide to.
Indeed it would be very weird to have a Lenient modifier everywhere.
There may be the opportunity to have a couple of switches in the code that would be fed a parameter that would modify the output of such errors.
This is going to be R&D work for us in Servant. If you need a quick-fix, please use a reverse proxy that rewrites the payload of 4* and 5*-type HTTP statuses.
I'm not familiar with reverse proxies at all, do you mind showing a quick example on how to achieve this? If possible, I'd only like to rewrite the payloads containing aeson error messages (and whatever else that potentially displays server internals) as I still need to send custom error messages as part of my API.
@qwbarch Well for nginx, you just use the error_page directive: https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
I see, thanks for the resource!
Could this be handled with https://docs.servant.dev/en/stable/cookbook/custom-errors/CustomErrors.html ?
Clearly it could.