-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Whitelist keys #66
Comments
|
Sorry, I don't really understand how it is related to whitelisted attributes. I don't want to enforce key presence, I want to make sure that no other keys but allowed can be passed. |
It is not forcing you to have certain keys. white_lister = Dry::Data['hash'].schema(bar: 'string', baz: 'string')
white_lister.call(params) # => only "white listed keys" Using Dry::Validation::Schema result = my_form_validation_schema.call(params)
if result.errors.empty?
result.params # => only contains keys specified in the schema, i.e "white listed"
end Note that you can have |
That's exactly what I needed, thank you.
where UpdateProfileSchema is empty:
|
Hey, I don't see this happening with
|
I'd consider this as a bug. schemas should only output defined keys. I'll fix that in next release. |
@waiting-for-dev yeah, currently you need to check the result for errors first. |
Ok, thanks you both for the quick feedback |
BTW I'm planning to experiment with a setup where separate schemas are used for pre-filtering input and then actual validation schemas can be inferred from these in order to apply additional business validation rules. This way we could have pure application validation schemas with business rules and a nice sanitization layer in front of it. The benefit would be a really good separation of concerns where input is sanitized and properly coerced so that we don't have to worry about our business validation process to crash on some stupid type-related issues. Currently my thinking is that handling both in one place is too much complexity and it mixes too many concerns (ie type coercions vs applying a business rule to a coerced value). |
And do you think this should be in I have these doubts because, in my current situation, I need to perform one sanitation or another depending on the user, because not all users are allowed to update the same set of attributes. In this scenario and with current
On the other side, different schemes would be better for very complex scenarios (but anyway you would be able to do that). This could be a complete replacement (and improvement) for |
@waiting-for-dev I don't think you you would need separate schemas for each scenario. You just need a context-aware schema where your user is the context. So we can make something like that possible: class Schema < Dry::Validation::Schema
key(:amount).maybe
rule(:amount_valid) do
account_updater? & value(:amount).filled?
end
def account_updater?
user.has_role?(:amount_updater)
end
end
schema.with(user: user).call(params) |
@waiting-for-dev oh and no, there's no need for a new library, I'm just trying to figure out how exactly I want to use this one :) |
@solnic , running validation against certain context ( |
Oh, great, I didn't know about the |
@waiting-for-dev uhm, I wrote that we can make it possible, it's not implemented yet :) |
Damn, I was already excited by that =P |
I'll add it tomorrow |
❤️ |
@waiting-for-dev @kwando |
Anyhow, I'm now wondering if |
Hey! Many, many thanks @solnic :) Now I'm out for three weeks without the computer, but when I come back I'll try it. About your comment, to be honest I'm not sure. Looking for a way to sanitize has been my first approach to dry-validation in a project, so I have no experience in other use cases. But surely it makes more sense to make it optional, or you'll end up with another issue asking for the opposite :) |
This is now done. You can configure schema's input processor, ie: Dry::Validation.Schema do
configure do
config.input_processor = :sanitizer
end
key(:email).required
key(:age).maybe(:int?, gt?: 18)
key(:address).schema do
key(:city).required
key(:street).required
end
end
result = schema.(
email: 'jane@doe',
age: 19,
such: 'key',
address: { city: 'NYC', street: 'Street', wow: 'bad' }
)
result.output
# { email: 'jane@doe', age: 19, address: { city: 'NYC', street: 'Street' } This comes with a bonus - a sanitization input processor holds information about the schema structure and types. It's using dry-types' schema = Dry::Validation.Schema do
configure { config.input_processor = :sanitizer }
key(:email).required(:str?)
key(:admin).required(:bool?)
key(:age).maybe(:int?)
end
types = schema.input_processor.type.options[:schema]
puts types[:email]
# #<Dry::Types::Definition primitive=String options={}>
puts types[:admin]
# #<Dry::Types::Sum:0x007fe86b53c270 @left=#<Dry::Types::Definition primitive=TrueClass options={}>, @right=#<Dry::Types::Definition primitive=FalseClass options={}>>
puts types[:age]
# #<Dry::Types::Sum:0x007fe86b9da250 @left=#<Dry::Types::Definition primitive=NilClass options={}>, @right=#<Dry::Types::Definition primitive=Integer options={}>> |
Hey, that's great! Thank you very much for your effort on this :) |
That's great. Thank you, @solnic |
Is it possible to create a white list of keys for a hash? I'm using DryValidation instead of StrongParameters and it's sometimes fine, but in some other places I have to ensure that only whitelisted attributes are allowed to be passed. Basically that's what
params[:foo].permit(:bar, :baz)
does.The text was updated successfully, but these errors were encountered: