allowUnknownBody is gone, but there is no alternatives provided for refactoring in changelog

[fega]

[AndrewKeig]

hey, Joi supports this like so:

const schema = {
  headers: Joi.object({
    accesstoken: Joi.string().required(),
    userid: Joi.string().required(),
  }).unknown(),
};

[isaachinman]

@AndrewKeig That's not ideal, as it doesn't support empty body/params/headers very well. We'd have to include an empty Joi.object({}).unknown() every time. Thoughts?

[papandreou]

I agree that especially for req.headers and req.body, Joi.object({}) provides a bit of a rough default when it comes to extra properties. For that reason I've ended up wrapping express-validation in my own app, which applies these options to the headers and body schemas:

validator = validator.options({ stripUnknown: true }).unknown(false);

Only applying .unknown() is bad, because it means that those unknown properties slip past the validation schema:

const Joi = require('joi');
Joi.object({ foo: 123 }).unknown().validate({ foo: 123, bar: 456 })
{ value: { foo: 123, bar: 456 } }

whereas:

Joi.object({ foo: 123 }).unknown(false).options({ stripUnknown: true }).validate({ foo: 123, bar: 456 })
{ value: { foo: 123 } }

My wrapper is also enforcing a schema of Joi.object({}).unknown(false).options({ stripUnknown: true }) for the locations where no schema is specified. This avoids the footgun of forgetting eg. a body validation schema for an endpoint and just consuming unvalidated input.

It would be nice if this library could provide safer and friendlier defaults regarding these things. To some extent this need was previously served by being able to specify eg. allowUnknownBody globally via:

require('express-validation').options({ allowUnknownBody: true });

However, a conscious decision was made to remove this ability in 3.x and delegate all of the validation to Joi. I'm not really sure how to address these needs except by partially undoing that big change. As a new co-maintainer I'm not really comfortable doing that. For now I still I'll stick with that wrapper myself. Maybe it could turn into a slightly more opinionated alternative to (or wrapper around) express-validation.