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

Introduce ransack! so that invalid filters raise an exception #535

Closed
linkyndy opened this issue Apr 29, 2015 · 3 comments
Closed

Introduce ransack! so that invalid filters raise an exception #535

linkyndy opened this issue Apr 29, 2015 · 3 comments

Comments

@linkyndy
Copy link

It would be very useful to provide a method, ransack!, that will raise an exception if, say, a filter is not valid. Here's an example:

class Client
  has_one :address
end

class Address
  belongs_to :client
end

If you do:

Address.ransack('client_name_cont' => 'bla')

and name is a valid field of Client, the above would work. But if you do:

Address.ransack('filter_not_existing_cont' => 'bla')

an error would be more appropriate to be raisen instead of returning all addresses (SELECT "addresses".* FROM "addresses").

I find ransack! to be very useful; what do you think?

@jonatack
Copy link
Contributor

Hi @linkyndy, there is a configuration option ignore_unknown_conditions described here in the wiki, that when set to false raises if a query contains an unknown predicate or attribute. Do you mean something like that, or something different?

@linkyndy
Copy link
Author

Indeed, that's what I was referring to. While it's already there, I believe having a ! counterpart to ransack would be both intuitive and helpful.

@jonatack
Copy link
Contributor

Feel free to make a PR 😃

oneamtu added a commit to oneamtu/ransack that referenced this issue Dec 12, 2018
Hi,

Big fan of ransack! We've been using it at my company for a while now. One thing that we bumped into recently is that, by default, if you pass in a malformed parameter to ransack, it will ignore it, and by default return the whole collection. That's proved to be an unsafe way to operate for us, since it opened up clients who use our APIs to the possibility that they'll have a badly named search term, and instead of scoping the data to one person, they'll get a bunch of people's data. We did some digging, and discovered `ignore_unknown_conditions`, and will use that in all our apps. I wanted to see if you all would be open to changing the default behavior, since it seems like having `ignore_unknown_conditions => false` is a safer default than the current one. 

Seems like other people bumped into this at times unexpected behavior in the past.

activerecord-hackery#852
activerecord-hackery#535

Either way, thank you maintainers for your continued work on this gem. Cheers!
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

2 participants