Moves On Rails

Rails/Javascript programmer at Nedap

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Thu, 18 Dec 2008 23:41:00 +0100

Location: Groenlo, The Netherlands

Nedap Healthcare, market leader in the dutch home healthcare sector, is looking for a skilled and motivated web developer with a knack for interaction design. We provide an inspiring work environment with a mixture of coding and direct contact with our customers.

Even though Nedap is a fairly large company we work in small teams. Should you choose to accept, you will become the fourth member of our Moves team. Moves is a two year old web application that is sold to home healthcare organizations in combination with a 24" iMac. It allows planners to create routes that make the client, nurse and managers happy. If you want some more info about what we build and how we think, check our blog (listed below).

As a developer you should be proficient in HTML/CSS/Javascript and Ruby on Rails. Flash is a bonus, just like photoshop skills. Working in the healthcare business, we aim to develop most of our code using a BDD methodology.

We are based in Groenlo, a small dutch town near the german border. Though we are not necessarily looking for an on site developer we do prefer someone who is able to drop by from time to time regularly. Freelance is an option if you prefer.

We are offering a great job and unique company culture. It is important to us to build an excellent product by cherry-picking great people, not by bloating our team.

To apply If you are interested send your resume to andre.foeken@nedap.com

Trust

andre.foeken@movesonrails.com (Andre Foeken) — Thu, 27 Nov 2008 21:57:00 +0100

Every time I read a set of terms and conditions attached to a piece of software my heart bleeds a little. I wanted to share a small excerpt from a dutch company that I translated. I replaced the company name.

The product in question is a web-based tool for small/medium sized companies to handle their invoicing. Some would consider this piece of software 'critical' to the companies' survival.

Would you trust this company with your finances if their terms stated the following?

We have the right to close any account, with or without notice. If you lose content because of this we are not responsible.

Wow! At any moment they may decide to kill your 'critical' business proces. This doesn't feel right... But it goes on.

We preserve the right to suspend or stop [product] at any time, with or without notice.

In other words: if we get bored, we can just quit. We don't even have to tell you!

In my opinion the next one is characteristic about what is wrong with the software industry as a whole.

We don't guarantee that: 1) [product] meets your specific requirements, 2) [product] works correctly, 3) errors in [product] will be fixed.

One can argue about the first point but the last two? Would you accept this behaviour if you bought a car? Luckily they have a specific condition in their terms to handle their customers reaction to these terms!

Every form of threat/contempt directed at [company] employees will result in immediate closure of your account.

Well there you have it, unfortunately some terms might be required to protect your startup from the big bad world around. But using your terms to give yourself an easy way out? Dubious.

RoR Workshop - 26 nov 2008

andre.foeken@movesonrails.com (Andre Foeken) — Wed, 26 Nov 2008 19:44:00 +0100

This afternoon we held our first Ruby on Rails Workshop at Twente University. We got 20 Apple MacBooks together and allowed 25 people to bask in the glory of Rails!

We want to thank everyone who attended for their enthousiasm and energy. We had a great time! Also great thanks to Pragmatic Programmer for giving us a good deal on their latest Rails book and Inter-Actief (Michel) for their organisational skills.

Below are the sheets we used, courtesy of SlideShare.

Nedap Rails Workshop

View SlideShare presentation or Upload your own. (tags: nedap rails)

User Authorization in Rails

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Wed, 22 Oct 2008 10:51:00 +0200

A lot of rails apps use some form of user login. Usually a user identifies itself by entering a username/password combination into a form. The application will then check the combination and use the session of the user to store which user authenticated for that session.

Plugins like acts_as_authenticated give a nice starting point, but must applications write authorazation themselves as it is quite simple to do in Rails. If you have done this too, then here are a number of security points which such login process should take into account.

Brute forcing

Rails apps are usually tweaked to respond to requests as quickly as possible. If a response is slow, it will block my mongrel! This makes Rails apps a very good partner for the brute forcing of passwords. Action against this is surprisingly simple. You can count the number of incorrect login attempts. If this becomes more then 10, let the user enter a captcha. Or really degrade the login by rejecting every login attempt with a 403, when the last incorrect login attempt was less then two or three seconds ago.

HTTP login posting

Many sites offer a login box on their front page. This is a very user friendly and I would be the last person to tell you not to do this. However, this often means that you are letting a user authenticate over HTTP, which is not very secure. Anyone snooping the traffic of that user will see a plaintext username and password being posted to your site. Poke around with Webscarab or Firebug in Firefox to pick up on these things easily.

Solutions are again easy. If you have a HTTPS part of your site, make sure the login form posts to it. If you do not have HTTPS, you can encrypt the password in the clients browser with javascript via a public/private key combination. A lot of good examples of this can be found all over the internet.

Session hacking

At the moment Rails supports two types of sessions. It can reside serverside in a file or database and clientside in the cookie of the client.

We will first discuss the server side session, as this was the default before Rails 2.1. When a user connects to your website, he will automatically receive a unique session id. This is is the only thing your application can use to distinguish between unique users and their requests. The default session ids in Rails are generated correctly, so that is very hard for someone to guess ids of other users using your application. But if a hacker does acquire a session id of another user, Rails will not offer you any protection by default. And there actually quite a few ways for a hacker to obtain session ids of other users. The two most commonly used being: Cross Site Scripting exploits (XSS) and code injection.

Why is this a problem? Well if an attacker shares a session id with another user, and that user logs in, the attacker will share their session. This means that the attacker will have the same privileges as the user. Countering this can be a bit of a hassle, but as every application is sure to have a XSS exploit somewhere, it is a hole that is important to plug.

First you need to reset sessions after a logon. This will counter any creatively crafted URL attacks. Secondly it is a good idea to fixate your sessions on the ip used in the login attempt and you also should take a look at sesion expiration.

Clientside sessions have the same problems, so don't count on them as being the ultimate solution.

SQL injection

Initially I wanted to leave this out, i as the problem is still so common, I decided to have it here anyway. Rail does provide you with SQL injection protection, but you still have to use it correctly in order to be safe.

User.find(:conditions =>
   ["username = #{username} AND password = MD5(#{password})"])

User.find_by_username_and_password(username, SHA(password))

They both work, but the first one can be easily exploited through SQL injection.

Conclusions

This will not magically fix all your user authorization problems, but it should point you in some interesting directions. Want to read more? Here are a few good places to start reading.

http://guides.rails.info/securingrailsapplications/security.html http://www.rorsecurity.info

Friday afternoon ...

andre.foeken@movesonrails.com (Andre Foeken) — Fri, 26 Sep 2008 16:47:00 +0200

A nice time to build a realtime thermometer of the usage of our latest product...

Webrat Story Steps driving Selenium

andre.foeken@movesonrails.com (Andre Foeken) — Thu, 11 Sep 2008 09:32:00 +0200

From now on driving Selenium with your stories is a breeze. If you have been using the webrat_story_steps plugin (available here ) you can now add a single file and get started right away. You don't even have to rewrite your stories (unless you have some custom steps, that took me about 10 minutes to rewrite)!

The new changes to the plugin require you to do some installing beforehand (2 gems and 2 other plugins) but after that it's easy.

Simple Net::Http stubbing / mocking

andre.foeken@movesonrails.com (Andre Foeken) — Wed, 03 Sep 2008 08:57:00 +0200

Recently I've been implementing a simple web-service protocol that used Net::Http instead of ActiveResource magic. Although it was easy to mock ActiveResource objects, I found it hard to find any intel on how to mock actual Net::Http calls.

Below is a very basic example (which you can easily expand to fit your needs) of how to mock your calls. The example below shows a simple snippet that results in all 'posts' to be result in a Net::HttpSuccess object with a given XML body (which you can define)

Now define the XML data as follows:

Net::HTTP::xml_data = nil

Lighthouse Keeper 1.0

andre.foeken@movesonrails.com (Andre Foeken) — Fri, 29 Aug 2008 16:21:00 +0200

It's always great to see how a great concept can become even better. Lighthouse has been our issue tracker for quite some time now and we've been very happy with it so far. But I always felt something was missing. I don't mind going to a web page when I want to report an issue for some open-source project or to post a message to a dev, but during working hours I like to be as efficient as possible.

One of my pet peeves has always been that it takes such a long time to find a specific ticket when you don't have a browser open. Sometimes we get helpdesk calls and then it's always good to see if an issue is already in the system. To figure this out we need to open safari, go to lighthouse, log in, go to the tickets page, click search, figure out a search term and wait for the page to load. All in this process can take quite a while.

Using Lighthouse Keeper this has been reduced to Command-Tab, click search field and go. Instant results, so no more waiting. But we still have all of the advantages of the web-based system we've come to love. Sure the program has some rough edges but nothing that cannot be resolved with a few minor updates.

I recommend every Lighthouse user to take a look at this nifty little program, and at € 30 it's a real steal. Keep up the good work guys!

Webrat Story Steps

andre.foeken@movesonrails.com (Andre Foeken) — Tue, 19 Aug 2008 14:11:00 +0200

We have just released a plugin for Rails making it much easier to use Rspec Stories for your integration tests!

Clone it here from github.

No longer will you have to figure out your own grammar. We have done it for you. Now you are able to write stuff like this out of the box:

    Given a user with username 'Dummy' exists
    And it has password 'monkey'

Even relationships (has many and belongs to are supported!)

    Given the administrator is logged in
    And a user with username 'A' exists
    And the user with username 'A' has a responsibility for / 
    the role with name 'Administrator'

Naturally we also support a lot of clicking, selecting and checking!

    When he clicks the 'Admin' link
    And he clicks the 'Roles' link
    And he clicks the 'Add a new role' link
    When he selects 'Planner'
    And he clicks the button

Even simple Javascript popups!

   Then he should see a popup with the message 'Are you sure?'
   When he confirms the popup

And it's simple to extend. We extended it to allow us to check our importer.

    Given the latest version of iO Connect is used
    And there are no addresses in the system
    When a client with objectId '1' is created in iO
    And an address with street '1st' is created in iO
    And the importer has been run

    Then an imported address with street '1st' should exist in Moves

Rails Request log analyzer

bart.tenbrinke@movesonrails.com (Bart ten Brinke) — Thu, 14 Aug 2008 22:58:00 +0200

You've probably all been there: your application is running slow, but why? What views or actions are clogging up the mongrels? Or are the mongrels just waiting for the database?

Request log analyzer is a simple but very powerful command-line analysis tool to quickly determine what is taking time, on all kinds of different levels. At the moment it can tell you the following statistics:

Top 10 most requested actions
Top 10 actions by time - cumulative
Top 10 actions by time - per request mean
Top 10 worst DB offenders - cumulative time
Top 10 worst DB offenders - mean time
Mongrel process blockers (> 1.0 seconds) - frequency
Requests graph - requests per hour

For an example run, or the analyzer take a look at the github. http://github.com/wvanbergen/request-log-analyzer/

To install, run:

sudo gem install wvanbergen-request-log-analyzer --source http://gems.github.com