Fail validation on unexpected input

[HoneyryderChuck]

Hi. this might be interpreted as a usability issue with the library, but I don't want to create an account with gitter, as it requests for too much information from my github account, making it difficult to join. If I may be so bold to suggest smth, a mailing list would have a lower barrier of entry.

Complete Description of Issue

I'm using reform contracts in the context of trailblazer for schema validation of a REST API. I've seen that unexpected properties being sent in a JSON payload will just be "cleared out", instead of generating an error. It has been said to me that this mimmicks the behaviour of rails strong parameters, which will also remove unexpected input, so I don't really have an issue with that. But I'd like to opt-in on different behaviour, i.e. fail the validation and generate errors like "Unexpected attribute" for wrong input. An example would be this kind of payload:

{"user": {"firzt_name": "John", "last_name": "Doe"} }

In this case, I'd like to generate an error for the firzt_name key, as the contract only states the first_name and last_name properties.

Is this actually configurable? Or is it completely missing?

[apotonick]

Hi @HoneyryderChuck - this is missing. The underlying parser, the Representable gem, doesn't support this out-of-the-box. You could probably do that manually in a "virtual" populator, since it receives the parsed fragment.

BTW, the "clearing out" is due to the parsing gem, which existed many years before strong_parameters, any similar behavior is not intended. :stuck_out_tongue_winking_eye:

[HoneyryderChuck]

@apotonick thx for the reply.

You could probably do that manually in a "virtual" populator...

Where do I find a tutorial on how to use a virtual populator?

BTW, the "clearing out" is due to the parsing gem..

I guess it makes sense to have this as the "default" behaviour, as this was probably done more to support url-encoded form validation, and JSON schema validation requirement came later. I'd say that one could keep it as the default, and "opt in" to an explicit failure. How hard would this be to implement?