Authorisation: Conditions of entry for web applications

We recently deployed a complete reimplementation of the user management and authentication part of our customer web platform. This now includes user authorisation - I think this time we mostly got it right, touch wood.

Authorisation in software applications is tricky to get right. There are always a hundred opinions on how it should be done, in introduces a heap of corner cases that you didn't anticipate and you often end up with something that is much more complex than what you really need.

I have had the chance to implement authorisation for different web applications. Over time I have build up a list of considerations to review before blindly running down the implementation path.

Pomodoro sauce for development teams

We recently started using the Pomodoro technique in our development team. Pomodoro technique is a time management method that specifies working in 25 minute blocks with short breaks in between. A 25 minute block is called a pomodoro. 

We have adapted it a little for our purposes. We work as a team in synchronised pomodoros and then have a mini standup after each. Each week we assign a pomodoro master that is responsible for managing the process - start pomodoros, keep time, count the completed pomodoros, etc. 

One of our team members, Steve Occhipinti (@steveocchipinti),  developed a handy web app to keep time and provide visibility to all team members. It can be found at http://pomodoro.stevenocchipinti.com/. The intention is to display the timer on a big screen to be visible to everyone in our area.

Working this way has had a number of benefits. In general the team is much more focussed. Individuals and pairs focus on one task for 25 minutes without allowing themselves to be distracted. We try to defer external distractions until the end of the pomodoro. Its easy to point to the pomodoro timer and ask someone to give you X minutes to finish what you are busy with. Also, IRC and emails do not get attention until the end of the pomodoro. 

Staying on top of Ruby on Rails security

Maintaining a Ruby on Rails application and keeping it secure might feel like a challenge with all the security attention that the framework has received recently. Here are my suggestions for staying ahead of the curve.

Read the Ruby on Rails Security guide - This guide discusses security best practices when writing Ruby on Rails code.

Join the Ruby on Rails Security Google group - Every patched Ruby on Rails vulnerability gets announced in this group.

Familiarise yourself with common web application security risks - The OWASP Top Ten is a great source for this: site and document.

Keep an eye on your popular gems for security patches - Devise, Rack and JSON recently had vulnerability patches.

Have an automated security scan as part of your build pipeline - Automated scans can not give you 100% confidence in your security status but it will highlight the most obvious flaws to you. Brakeman is a popular security scanner for Ruby on Rails that is easy to integrate with Jenkins.

Be ready to patch and deploy quickly - Be prepared to update and go to production at any point, be this on an application or infrastructure level. Adopting a Continues Delivery model will empower you to do this very easily.

Understand your application security threats and objectives - Threat modeling is a popular exercise to achieve this. It can be a formal process or a less formal process - the important thing is that you understand your application's security threats and objectives.

Have a security evangelist in your team - Give someone in your team the responsibility to take ownership of promoting security in your projects.

Other useful resources - Ruby Security, OWASP Ruby on Rails Cheatsheet

Successful pair programming interviews

We've introduced pair programming as part of our interview process at REA a while ago. In general I think its been quite a success. Its a great way to get a perspective on a candidate that you otherwise won't get. You see a bit of how they work first hand, instead of trying to infer it from a conversation.

The following is a list of things that I find helpful to get the most out of a pair programming interview.