My first thought about your question is “be careful!” You’re playing with fire. It is very possible to sanitize your inputs but you’ve got to be very thoughtful about it.

There are many ways to solve the “operator in the input” problem - I think a case statement is the safest. So as you loop through your various inputs in params, you can do a regex match or something in your input names:

%r{(.*)_(gt|lt|eq)}

\1 would be your field name
\2 would be your operator symbol

In Postgres (the db I use), it’s possible to escape columns as well as escape values. In Pg, you use the double quote (”) to signify a column name, so if your table is “property” and your field is “price” you would write sql like:

“property”.”price” > 500

There’s lots more in this subject - keep in touch as you work on this stuff!

One thing I struggle with in my own search application….How and when do you sanitize SQL inputs when the entire input is form driven?

E.g. Normally, SQL can be escaped using syntax like:

Model.find(:all, :conditions => {”name = ?”, params[:name]})

But in my case, the column name (”name” in this case), the operator (”=” in this case), and the value (params[:name) are all specified in my web form.

Trying to sanitize all of that produces a WHERE statement like this:

… WHERE ‘table.name’ ‘=’ ‘value’

which isn’t valid due to the presence of the quotes around the equals sign. Likewise, the column name is sanitized as ‘table.column’ instead of ‘table’.'column’.

The reason I have it all form driven is that I want users to be able to pick which column to include in the search, what criteria (equals, not equals, greater than, like, etc…), and then the value.

Any thoughts?

From an HTTP perspective, GET vars are stored on the URL line in format http://site?get_var1=val1&get_var2=val2

POST params are included in the HTTP payload associated with the URL - mime encoded iirc. But you don’t have to worry about that difference at all in Rails.

The main difference between a GET and a POST in Rails is whether you access your controller/action via a FORM submit or a link. In general FORM tags submit via POST and anchor () tags submit via GET. You can alter this in various ways but that’s the basics. Hope it helps.

My solution is to use POST to hide “supplemental” search variables, and store those variables in session. Then I merge any new incoming POST vars with anything already in session to create a picture of the current search.

Your method of storing search params on the URL line is totally valid and workable. It’s also simpler, as you put the persistence where it really belongs: inside the correct tab of the client browser’s application. This establishes “state” of the application correctly with no additional work (no merging in/out of session).

The potential downsides of your approach are:

1) If GET URL line is too long, your method fails.

2) If you must have a relatively “clean/tidy” URL line, your method fails.

Here’s an obscure edge case for case #1 above, just as an example: What if your app gets really popular and you want to optimize your searches to store all the ID’s for a given search - and then permit refining the search more narrowly over time against that initial set of ID’s. That will speed your query times. But if the ID set is long, the GET line will not store them all. Session (and hidden input tags) do not have this problem.

I asked you there about the use of parameters ( ?foo=bar) vs. URL routes (implied URL parameters ala /this/is/a/parameter on links, and we didn’t get a chance to finish our conversation.

You mentioned that you would use “javascript” or POST instead of GET parameters when adding non-SEO essential parameters to a search query, however I am a bit confused by this and it seems to be kind of hacky and alot like ASP.NET “PostBack” concepts which are not very web friendly. Any thoughts on how to format URLs for drill-down searches on non-SEO essential parameters?

foo.com/USA/New_Jersey?type=condo

not cool?