Open Lucsanszky opened 2 years ago
I'm not sure if there was a particular reason, other than that in most cases, a server is only interested in whether a client sent the correct data in the token or not (and would not return an internal parsing error to the client). It could certainly be more useful to have that information logged though to potentially help debugging why the data is invalid.
I guess we could add an eitherDecodeClaims
function mirroring the Aeson functions. That would avoid breaking existing code. Alternatively we could make the change and bump the version number. I believe there are issues with Aeson 2 which will probably require a version change anyway.
I was using the library at work and since
decodeClaims
is usingdecodeStrict'
from theaeson
library, no meaningful error message is returned if parsing fails. I think it would be better to useeitherDecodeStrict'
in order to have more information if parsing fails. Is there a good reason whyeitherDecodeStrict'
was not used in the first place? If not and you think it would be beneficial to useeitherDecodeStrict'
, then I would be happy to have a go at making those changes and modifyingBadClaims
to have an additional parameter which would carry the error message returned fromeitherDecodeStrict'
.