[2.0] Disallow non-primitive values for query parameters #44
Milestone
Comments
jgraichen
added a commit
that referenced
this issue
Jan 17, 2025
Restify checked every param if it responds to to_param, and calls it,
before passing values to Addressable::Template. Since Rails patches
to_param into anything, that resulted in accepting virtually anything
somehow into params.
For example, any Array was encoded a slash-delimited string of the
individual values ([1,2] -> "1/2"), which not only could result in
confusing things accidentially passed as params, but also made it
impossible to pass a parameter multiple times (a: [1, 2] -> "a=1&a=2").
This commit takes the basic type detection from Addressable::Template
and tries to only apply to_param, which addressable does not support at
all, for non-basic types. Therefore, arrays and hash, should behave
similar to when passed directly to Addressable::Template, but it will
still be possible to e.g. pass an ActiveRecord model as a parameter,
using #to_param.
This makes passing standard and Rails-style argument lists possible:
expand(p: [1, 2]) -> "/?p=1&p=2"
expand('p[]': [1, 2]) -> "/?p%5B%5D=1&p%5B%5D=2"
Fixes #44
jgraichen
added a commit
that referenced
this issue
Jan 17, 2025
Restify checked every param if it responds to to_param, and calls it,
before passing values to Addressable::Template. Since Rails patches
to_param into anything, that resulted in accepting virtually anything
somehow into params.
For example, any Array was encoded a slash-delimited string of the
individual values ([1,2] -> "1/2"), which not only could result in
confusing things accidentially passed as params, but also made it
impossible to pass a parameter multiple times (a: [1, 2] -> "a=1&a=2").
This commit takes the basic type detection from Addressable::Template
and tries to only apply to_param, which addressable does not support at
all, for non-basic types. Therefore, arrays and hash, should behave
similar to when passed directly to Addressable::Template, but it will
still be possible to e.g. pass an ActiveRecord model as a parameter,
using #to_param.
This makes passing standard and Rails-style argument lists possible:
expand(p: [1, 2]) -> "/?p=1&p=2"
expand('p[]': [1, 2]) -> "/?p%5B%5D=1&p%5B%5D=2"
Fixes #44
jgraichen
added a commit
that referenced
this issue
Jan 17, 2025
Restify checked every param if it responds to to_param, and calls it,
before passing values to Addressable::Template. Since Rails patches
to_param into anything, that resulted in accepting virtually anything
somehow into params.
For example, any Array was encoded a slash-delimited string of the
individual values ([1,2] -> "1/2"), which not only could result in
confusing things accidentially passed as params, but also made it
impossible to pass a parameter multiple times (a: [1, 2] -> "a=1&a=2").
This commit takes the basic type detection from Addressable::Template
and tries to only apply to_param, which addressable does not support at
all, for non-basic types. Therefore, arrays and hash, should behave
similar to when passed directly to Addressable::Template, but it will
still be possible to e.g. pass an ActiveRecord model as a parameter,
using #to_param.
This makes passing standard and Rails-style argument lists possible:
expand(p: [1, 2]) -> "/?p=1&p=2"
expand('p[]': [1, 2]) -> "/?p%5B%5D=1&p%5B%5D=2"
Fixes #44
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, we rely on Rails'
to_paramto pre-serialize values for use in query strings. That means, things like arrays ([1, 2]) are turned into strings separated by slashes ("1/2"). That is very arbitrary and should not be Restify's concern.Let's disallow these cases (needs a clear definition of what cases are allowed).
This would be a subtle, but impact-ful BC break, so I would propose to target this for 2.0.
The text was updated successfully, but these errors were encountered: