Just realized my proposed approach won't work for normal Dry::Validation.Schema schema's as they will by default use the NOOP Input processor (https://github.com/dry-rb/dry-validation/blob/master/lib/dry/validation/schema/class_interface.rb#L11). I guess a more generic solution is needed.
Did I correctly understand : when using the default Dry::Validation.Schema input keys not specified as 'required' or 'optional' will be ignored by validation and still be present in the output ?
I.e. when using default Dry::Validation.Schema:
- InputProcessing step : the given input data will simply be returned unaltered by the NOOP processor
- InputRule step : the unaltered input data is provided to do custom handling
- Rule step: only the specified 'required' and 'optional' key validation will be handled, thus ignoring unspecified keys
- calling output on the result of the validation still contains the unspecified keys
If so , this seems strange as I expected the output to contain only the 'trusted' data based on the specified validation rules which is the case when using Form or JSON validation schemas (it actually feels like a bug to me...).
I was able to get 'trusted' output by adding the following to my schema :
configure do |config|
config.input_processor = :sanitizer
However this solution has 2 disadvantages :
- I cannot act upon unspecified keys, similar to the case with Form & JSON + I cannot reuse the same patch as this time different Dry::Types are used...
- specifying uncoercable input data is not safely handled as with JSON/Form , for example provide a string as input data instead of a Hash will raise
NoMethodError: undefined method `keys' for "something":String
This last point seems actually a bug in the :sanitizer input processor? Let me now if I should create an issue ticket for this...
IMHO it seems dry-validation is missing a more generic system to catch unspecified keys and act upon them.
Perhaps an additional step can be added to the pipeline for this, however this means the complete input structure has to be processed again which would most-likely affect the performance....
Perhaps altering the 'InputProcessing' pipeline step to somehow store the unspecified keys (independently from the JSON/Form/Schema selection) and present them to the 'Input' pipeline step makes more sense.