Skip to content
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

Bug when parameters are empty string #51

Open
synth opened this issue Dec 28, 2015 · 6 comments
Open

Bug when parameters are empty string #51

synth opened this issue Dec 28, 2015 · 6 comments

Comments

@synth
Copy link

synth commented Dec 28, 2015

When a parameter is included in a request but is a blank empty string, there is unexpected and buggy behavior.

  • When params[:page] == "", #to_i is called on it, which causes the page to default to 0. Normally, the first page is 1. This may be equivalent now, but in the future may cause unintended consequences.
  • When params[:per_page] == "", this causes the error: "comparison of Fixnum with String failed".

I propose that when a parameter is included but is empty string that more defined behavior occurs such as falling back to a default.

  • params[:page] should default to 1
  • params[:per_page] should default to route_setting(:per_page).
@davidcelis
Copy link
Owner

Solution sounds good! I'm on vacation but would you like to take a stab at a PR?

@synth
Copy link
Author

synth commented Dec 30, 2015

So, after some digging, there seems to be some parameter coercion fixes in grape 0.14.0 that coerce empty string parameters to nil which basically addresses the issue. I'm locked on 0.13.0 due to another gem(wine_bouncer) so I'm not too sure on how to proceed. I filed a ticket on wine_bouncer to bump the version...

@davidcelis
Copy link
Owner

So does any action need to be taken here on my part, @synth?

@synth
Copy link
Author

synth commented Jan 1, 2016

Hmm. Not sure. Seems like it would be a good practice to better define behavior and not rely on grapes implementation so much. Who knows if coercion behavior will change in the future. At the very least I think it would be good to write tests to cover the behavior. I started some during my digging process(tdd ftw). I'll create a pr later this week and you can let me know what you think.

@davidcelis
Copy link
Owner

Sounds good, thanks!

@JiriChara
Copy link
Contributor

What about throwing some custom error if the page/per_page params are not numbers? This way programmers can catch that in the controller and either render 422 or parse the value on their own. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants