Response body validation does not work

[openreply-dleinhaeuser]

exegesis-express does not validate the body of a JSON response even if response validation is enabled with the onResponseValidationError option.

Steps to reproduce

• Install node v10.12.0 (current LTS) or newer.

• Extract the minimal example: exegesis-example.zip

• Run npm i && node .

• Send a GET request against http://localhost:8080/

Expected result

The server responds with status code 500 and message Response validation failed

Actual result

The server responds with status code 200 and message { "message": {} }.

Further information

Stepping through Response.validateResponse reveals, that response validation is skipped silently (in itself arguably not correct if a response specification exists) if the body is a string, which it always seems to be, even if the controller returns an object or calls res.json.

[jwalton]

I suspect this is an unexpected side effect of #53 @erykwarren. :(

[jwalton]

(Also, thanks for the detailed error report!)

[jwalton]

🎉 This issue has been resolved in version 1.2.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[erykwarren]

@jwalton Sorry for having introduced this bug :( . For what it is worth, swagger-tool did also parse the JSON to do the validation.

[jwalton]

No worries. It encouraged me to do string validation. ;) My original thinking was that it didn't make much sense to JSON.stringify the object just so we could turn around and immediately JSON.parse it again for validation, but you brought up a good point with .toJSON. maybe I'll add a `.fastValidation` option to disable it for folks who don't need it. :)

…

On Tue, Nov 27, 2018, 19:00 Eryk Warren ***@***.*** wrote: @jwalton <https://github.com/jwalton> Sorry for having introduced this bug :( . For what it is worth, swagger-tool <https://github.com/apigee-127/swagger-tools/blob/361c1f6f08aed64c8da1784cef5ea61a83bac787/middleware/swagger-validator.js#L127> did also parse the JSON to do the validation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsF-xtFhEqL01wRo1nSB3e6IdLctk5xks5uzdIsgaJpZM4YtlAr> .

[openreply-dleinhaeuser]

If the body is an object you could store it somewhere else before stringifying it and then validate that as an optimization.

[jwalton]

It's not quite that simple unfortunately. The thing that makes it complicated is that you can write a toJSON function on an object that will control how it is serialized:

const foo = {toJSON() {return "bar";}};
JSON.stringify({foo}); // returns '{"foo":"bar"}'

We're using ajv to do schema validation, and unfortunately it doesn't call into toJSON for us. So if you try:

const Ajv = require('ajv');
const ajv = new Ajv();
const validate = ajv.compile({
    type: 'object',
    properties: {
        myString: {type: "string"}
    }
});
validate({myString: 'bar'}); // passes
validate({myString: foo}); // fails

And, at first glance, you might think "Why would anyone care about this weird esoteric feature of JSON stringifiers?" But, if you use MongoDB (as a lot of node.js folks do), ObjectId is an object, with a toJSON() that converts it into a string.

So if there's an object with a toJSON(), we actually need to convert your response to JSON (or at least that object) and then parse it back before we can validate it. So we need to know ahead of time that you're not using any objects with toJSON(), or we need to traverse the response tree and check to see if you have any objects with toJSON(), or we need to give up and just do this for every response. :P

[openreply-dleinhaeuser]

You could do something like this (using lodash for brevity):

_.cloneDeepWith(body, (value, key) => {
  if ('toJSON' in value && _.isFunction(value.toJSON)) {
    return value.toJSON(key);
  }
  return undefined;
}

Question is of course, if this will be faster than serializing/deserializing and up to what size.
Maybe just not worth the hassle.