servant icon indicating copy to clipboard operation
servant copied to clipboard

Provide option to disable aeson decoding error messages

Open qwbarch opened this issue 3 years ago • 6 comments
trafficstars

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 avatar Jan 09 '22 07:01 qwbarch

@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.

tchoutri avatar Jan 09 '22 13:01 tchoutri

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 avatar Jan 09 '22 20:01 qwbarch

@qwbarch Well for nginx, you just use the error_page directive: https://nginx.org/en/docs/http/ngx_http_core_module.html#error_page

tchoutri avatar Jan 09 '22 20:01 tchoutri

I see, thanks for the resource!

qwbarch avatar Jan 09 '22 21:01 qwbarch

Could this be handled with https://docs.servant.dev/en/stable/cookbook/custom-errors/CustomErrors.html ?

alpmestan avatar Jan 10 '22 10:01 alpmestan

Clearly it could.

tchoutri avatar Jan 10 '22 10:01 tchoutri