-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
added undeclared params validator #810 #1158
Conversation
I like it. I think that the DSL could be clearer and be on I think I would like to be able to turn this globally on for my entire API. I'd like a way to turn this on gradually, we have 400 endpoints in a project and we would love to make params declared only, so maybe something like This will also let us specify a |
Something that's not declared is smuggled? Should |
Great, I would also prefer to have it on |
I've put it in there now, but it isn't easily testable and I haven't really found any similar behaviour in grape yet. |
I really like this. I think it needs README and CHANGELOG and it would be good to go. Testing via expecting a warning is good AFAIK. |
I had to change a bit more, to get the validation for generic hashes working in an expected way. E.g.: params undeclared: :error do
optional :config, type: Hash
end If you only specify the type Hash, you probably want to allow any Hash. In contrast, if you declared you Hash with a block like params undeclared: :error do
optional :config, type: Hash do
requires :language
end
end you have a strict expectation of how the Hash should look like. As for the warning test, I tried my best (even ugly stuff like expect_any_instance_of) but didn't manage to get a correct expectation running. |
When trying to integrate it into our own API I noticed that it failed when a Hash had more than one nested parameter defined. params do
optional :a, type: Hash do
optional :b
end
given :a => :b do
requires :c
end
end |
return k, convert_hash.call(v).to_h | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be refactored out of here.
Maybe there's a simpler implementation here that calculates a hash difference (only caring about keys), I haven't dug into things like https://github.com/liufengyun/hashdiff or others, but it sounds like a good way to abstract the problem, no? |
Yes, having |
f008ad3
to
94915be
Compare
What is the status on this? Is there anything we can do to help? This seems to be a quite important feature to me. Especially with being able to turn that on by default ('strict mode') for the whole API. |
I sadly won't have time to work on it in the forseeable future, sorry. I have no problem if anyone picks up where I left off and submits a new PR. |
I am still very interested in this, it's a super useful feature. Was thinking maybe we should have |
Closing this, as I'm currently clearing out old/outdated PRs of mine. |
Only allow declared parameters as proposed in #810.
Works like this:
Now if there is a parameter present that is not
beer
,wine
orjuice
a validation exception will be thrown.Also tested for nested parameters.
It is not quite finished yet:
except
option to skip the validator for some parameters. Especially in combination with the bug described in Nested mount points don't inherit parent declared params #1050 / namespace param validation doesn't propagate to nested Grape modules #1085 , a param that is accepted on every endpoint would have to either be declared in every params block or will throw an exception with this validatordeclared_only
would be nice. I not sure if it fits in well.