flash.now - did you know?

Well, I didn't know this until late. If you are like me, you have often wondered when you saw those unwanted flash messages appearing after a request, sometimes after ajax requests when you do a redirect, all on a sudden that flash shows up!
Well, as you have thought, the Ruby on Rails people have solved this problem way before now. The solution is to wisely use flash.now[] and flash[]. Here are a few tips:

Use flash.now[] when you are flashing:

• on ajax requests
• before a call to render :action => :my_action, as often found in failure cases of create and update actions

Use flash[] when you are flashing:

• before a redirect_to, often found in the success cases of create and update actions

In general, use flash.now[] when you don't want to carry over the flash to the next http request and flash[] otherwise. The FlashHash class has more detail on this at the ruby on rails API page. Hope this helps you to get rid of those annoying and often embarrassing out-of-context flash messages!

What's up next?

Hello Readers:
Wish you all are doing great as the Spring already started :-)
Recently my grad courses are keeping me busy with assignments and projects as the term comes close to an end. So, I haven't had much time to spend on blogging other than posting the Ruby on Rails link blog called www.DrinkRails.com. However, for my readers, I thought I would post the recent presentation that I put for the Agile course here:

But I am looking forward to start a new project with Wairever (www.Wairever.com), a Calgary based health care IT solution vendor. I hope that will fuel me with a lot of new concepts and as always, I will try to keep my learning posted here at my blog. Stay tuned! BTW, if you are Ruby on Rails developer or wanna be so, please let me know your feedback about the DrinkRails.com link blog.

Ruby on Rails Security Review: An Experience Report

Image credits to Wink on Flickr (creative commons)

I was reviewing a Ruby on Rails source code to see the security implementations they have so far. They are about to launch their product for the first release and wanted to ensure they have the most obvious things checked. So, in a sense it was not supposed to be a hacking job for me, rather to check if the most well known security measures are in place. This is what I looked into so far:

1. Password: Password was encrypted using a salt. However, the default logger would log the password as they didn't use the filter_paramerer_logging method.
2. Cross-Site Scripting: I was able to easily inject a script by just entering <script>alert('Script')</script> when I signed up to the system and every time it would open an alert window whenever I navigated to a new page! So, I recommended them to use <%= h %>. However, Rails 3 does a good job of making this a default.
3. Authorization: I found the weakest measure in the implementation of Authorization. For an example, there is a calendar in the web app where one can add/remove events. I found that any logged in user, not necessarily the event owner, could change/remove any calendar event. This was a shocker. Next, I found this same thing happening to the core models as well. The catch here is, they had a filter that checked if a user was logged in, but they didn't check if a user has rights to modify an instance of the object. For example, there is a project model, that can only be modified by the project owner. However, this per object ownership was not authorized and it was a huge potential security bug in my opinion.
4. File uploads: The app was designed to upload the files to a folder underneath the public folder. Which means, if the rails server was down, apache would serve the files directly to the user bypassing whatever security measure was taken inside the app.
5. PRG violation: This is a good idea to follow a post-redirect-get pattern when an object is modified through post/delete/put to ensure pressing the browser refresh button doesn't re-invoke the change. This wasn't done at some places which might end in multiple payments and such severe risks.
6. Direct public release: I was a bit concerned that they wanted to go public release with their first ever release, even before having an alpha or at least in-house user. This is important because this application deals with money and credit cards. Trust is very important for such apps. So, I advised them to try this for some real works at home other than the "asdf asdf asdf...."(!) kind inputs. This will help them spotting some of the odd behaviors early and cause less embarrassment.

It was only a 4 hour assignment for me. Also, I was only limited to the source code and the test deployment that they have now. However, it seemed to me that, they might spend a few hours to fix the obvious errors and do some in-house real use before going to a public release.

Ruby on Rails or Rails on Ruby?

All on a sudden, this thing popped up in my mind. What we are calling Ruby on Rails, is this actually "Ruby" on "Rails" or the other way around? Is this upside down? Here's my mental picture of the RoR framework:

Image credits to Foo Fighter on Flickr(creative commons)

1. Ruby is a self-sustained language. As a language this is completely ignorant of the Rails Framework. So, I think there is no dependency from Ruby to Rails.
2. Rails is a framework built using Ruby as a language. So, there is a strict dependency from Rails to Ruby.

What do you think? Would you call it "Rails on Ruby" or "Ruby on Rails"? I see a point of agreement for the ones who want to call it RoR, no damage done :-)

Lets see how this "on" preposition works for other language/platform pairs:

• Java on Struts vs Struts on Java
• PHP on Cake vs Cake on PHP
• C# on .Net vs .Net on C#

Confused? Well, then you can use RoR for now!