The Puerto Rican Rails Dude

Today I had a pretty frustrating moment. I made some new changes in the morning, which included the addition of a new column in the database. This field wasn’t required, but I needed to limit the amount of characters a user could enter in that string. So I did the proper thing and set this in my model:

validates_length_of :locations, :maximum => 200

I did a quick test, and the validations worked great. So I promptly committed the code to our repository. A few minutes later, our Continuous Integration system sent me a nasty E-Mail: I broke the build.

I frantically searched the errors in the test, and it seemed that the tests were expecting that field I just added to have something. I was stumped, thinking that unless you specify validates_presence_of, set a range of characters in the validates_length_of or perhaps some regular expression validations in the model, that would be the only time a model would require the field to be there. I hadn’t done any of these.

Frustrated, I added a simple string to the fixtures and the test code for this field, and the tests passed. Not content in just making something work, I needed to know what was up. So I started digging around, and found something that now seems obvious, but I totally ignored before.

Whenever you submit a form for a model in Rails to insert a new record in an ActiveRecord model, all the fields you have set in the view are passed in the POST request. However, if you didn’t enter anything in a field, the parameters for that field would simply be sent blank. In this case, validates_length_of doesn’t bitch about the missing field, because it’s there. As long as the number of characters - in this case, zero - isn’t more than what I specified in the model, it’s all good. However, the tests were failing because since I hadn’t specified that new field in the fixtures, the parameters were sending that field as nil, which caused the previously mentioned validation to scream out.

So just as a quick review:

• validates_length_of - Verifies if the field is within the amount of characters specified in the validation code. If no minimum is set, it won’t mind blank fields, but it will mind nil fields.
• validates_presence_of - Verifies if the field is nil or blank.

Like I said, it’s obvious now, but not so much when I was getting alerts that the build failed for some silly reason.

Today I noticed that whenever using some of the Prototype Helpers in Rails (such as link_to_remote or remote_function), it was setting by default the evalScripts parameter to true. For those who don’t know, Prototype uses evalScripts to evaluate anything in <script> tags from the response text. This was giving me major headaches in a piece of code today.

Looking at the previously-linked API page for the Prototype Helpers, there was no mention on how to set this parameter to false. I thought that simply passing :evalScripts => false as an option to the helper would do the trick, but it didn’t. So I had to dig into Rails source code to see if there was any way to set this to false.

When reading the prototype_helper.rb file, which houses the helpers that generate the HTML / JavaScript code, I noticed that there’s an option named :script that allows the developer to set the value of the evalScripts parameters in the generated JavaScript code.

In short, passing :script => false as an option to your Prototype Helper code on the view will correctly set the evalScripts parameter to false.

Hope this helps someone!

I just stumbled upon a script that MySQL includes nowadays called mysql_secure_installation. It runs a series of steps to remove some of the default installation options that MySQL installs, like an anonymous user and a test database. When you run the script, it does for the following:

• Prompts you to change your MySQL root password, especially if you haven’t set a root password yet.
• Removes anonymous access to your database server.
• Restricts root access to localhost only.
• Drops the ‘test’ table that’s installed automatically.
• Flushes the privileges so that all changes are taken immediately without having to restart the database server.

Here’s the output when running the mysql_secure_installation in one of my servers.

In all, it’s something that I’ve been doing manually for a while. And I bet that there are many, many developers out there who, even on production servers, don’t even bother to remove these things. Obviously, this isn’t the “be-all and end-all” of MySQL security, but it’s a big step away from the default installation. Go run this script now! Well, unless you’re a security expert who already did this, either manually or with the script. If so, then I salute you.