Misuse

I was at the (first) talk, and enjoyed it. I hope to catch the parts that had to be skipped for lack of time. Any chance of posting the slides in PDF format, not everyone has Office installed. Thanks!

Alderete: Glad it was helpful. Thanks for the suggestion! PDF is now the primary download. With the added benefit that the file is screen rather than projection quality and so is only about a meg instead of 11mb.

Great presentation, too bad it was cut off - probably the best format and style I’ve seen in all of the sessions (including the tutorials on Thursday, which were pretty bad).

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?

Hey Ed - That’s totally cool. The tricky part about my whole presentation is that I wanted to present a clear “pathway” for solving these problems, when in fact there are many many combinations that lead to valid solutions.

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 am new to RoR. How do you go about using POST instead of parameters in the urls?

mabed: The params object in Rails contains all POST and GET vars - merged together.

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.

Great presentation at RailsConf. It’s a hard enough problem to solve I sat in on both talks. I finally have a chance now to go back and re-read the presentation to try to grasp some more info.

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?

Aaron: Thanks for the kind words.

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!