Sep 11 2008
Rails Conf 2008
I attended Rails Conf 2008 in Berlin on the 3rd and 4th of September 2008. Following is a quick summary of the talks that I attended. There are loads interesting things going on in the Rails community. My opinion is very biased but I believe the Ruby on Rails community is setting the bar on future web development. And I think this both the case for the techniques and approaches that is practised by these developers and equally the Ruby on Rails framework that is the result of this.
Key note – David Heinemeier Hansson
David is the creator of the Rails framework and obviously a bit of a celebrity. Interestingly enough I get the idea that he is not the highest contributor to the Rails code base – I appears to be Jeremy Kemper which is his colleague at 37signals (the company behind Ruby on Rails).
David delivered the keynote on Wednesday morning. The key note was on legacy code. Initially I thought – “What a boring subject” and then later I caught myself thinking – “Now you are talking a load of nonsense” and two thirds into it I was happy to admit – “Hey, you really have been thinking about this a lot”.
Maybe it is a sentiment that only or mostly developers can associate with but very often you look back onto code and refer to it very cynically as “Legacy” code. He’s argument was that “legacy” code is a result of progress in environment and personal growth (Sounds like a psychiatry session – I know – It did get better). He carried on by making suggestions as to how legacy code should be dealt with and then showed a few examples in Rails. Some thoughts suggestion:
- The worst mistake that a company can make is to decide to simply rewrite legacy code on impulse.
- Legacy code should be put through iterations to improve it – They have a rule in their company that you should always leave code in a better state than what you found it in.
- Be careful of judging code as legacy due to a change in personal taste.
- Keep in mind that the code you write today will become legacy – face the facts.
Rails developers make a big deal out of DRY (Do Not Repeat Yourself). It implies that functionality should not unnecessarily be repeated in your code. The rule of thumb is that if you have found yourself copy and pasting for the 3rd time then its time to DRY-up your code. His point was that very DRY code makes it sometimes difficult to extend the code and this can make the improvement of legacy code difficult. A bit of repetition in your code is thus not a bad thing.
A thought that came to my mind was – “How should the IT security consultant look at (or judge) legacy code. Firstly, code tested 2 years ago and stamped as secure might not be secure anymore (new techniques, new vulnerabilities). What, or rather, is there a recommendation on re-testing or frequency on re-testing? Secondly, what is the recommendation on finding holes in legacy code? As mentioned rewriting code is not always (very seldom) the viable solution. How should a client maintain a legacy code base from a security point of view?
When to tell your kids about presentation caching – Matthew Deiters
You have all heard about the 20/80 rule. You wear 20% of your clothes 80% of the time. 20% of the world’s population own 80% of the wealth. And so it turns out that 20% of an application resources are being requested 80% of the time and 80% of the http request time are being spent on the wire - thus the argument for caching and a few other tricks to speed things up.
From my notes and memory the following are the major points:
- Rails supports ETags. The application responds with an ETag in the HTTP header when a request has been made for specific resource. The browser caches the ETag and the contents. When requesting the same resource in future it sends the ETag back the server. This allows the server to check if anything on the resource has changed since the last request associated with the ETag. If it is still the same it responds with “not modified” (that take is quicker to process and send) and the browser just displays the old version.
- Rails also supports static asset time stamping. This allows browser caching to be done based on a timestamp in the static asset request string.
- Rails has setting “perform_caching true” that combines .js files into a single file and makes the download time quicker.
- You can also configure your web server to gzip certain assets.
- Because most web browsers only allows for 2 connections to run simultaneously to a single server there are advantages in distributing you static assets across multiple servers.
All of the above have their little tricks and limitations that are worth investigating on implementation.
Intellectual Scalability - Solving a Large Problem With Multiple Cooperating Rails Apps - Frederick Cheung (Texperts), Paul Butcher (Texperts)
This was one of two presentations on serving multiple applications through a single front-end. In this case the developers designed a JavaScript heavy UI framework that presents the multiple allocations through a single front-end interface. Each application is presented in the front-end through what they call a widget. The power of the framework is in the code and a full (even partial) understanding requires a demonstration. I am making contact with the guy to see if they are willing to share the code. He did mention that they will release it publicly if there is interest.
Offline Rails Applications with Google Gears and Adobe AIR - Till Vollmer (MindMeister/Codemart GmbH)
(My notes are becoming increasingly less and I am not going to write a lot about this)
This was more a Google Gears talk than a Rails talk. I have never bothered to actually have a look at Google Gears but this guy had a good talk on how they implemented it from an architectural point of view.
You basically design your web application to be able to operate when you are offline. You have a local SQLite database that you use when going offline and this is synchronised back to the server when you go back online. There is obviously at lot to manage:
- Detect on-line/off-line status
- Clashes when local db and server are not compatible on synchronisation.
My biggest thought during this talk was the amount of havoc that you can cause when the contents of the SQLite db is not validated before the automated synchronisation to the server db takes place. I think it is worth looking at.
Security on Rails - Jonathan Weiss (Peritor GmbH)
This is a German chap that is (amongst others) an IT security consultant. It had nothing too new about the web application security stuff – XSS, SQL injection and XSRF. He discussed in each case how this should be prevented in Rails. It was reassuring to note that our Rails development is up to his standards.
The interesting part of his talk was on how to finger print a Rails application. I will leave you with his slides to have a look at that: http://assets.en.oreilly.com/1/event/13/Security%20on%20Rails%20Presentation.pdf
Few other important things:
- Rails 2 and greater by default uses the cookie to store the session state (you can change this). This cookie is just Base64 encoded and should thus not be used to store sensitive data. A hash of the data and a secret key (you can configure this) is also stored in the cookie and this is used to check the authenticity of a cookie when send back to the server.
- Some plugins to look at: saveERB, XSS shield and tidy_library.
- Often times (and this is the case in some trusted plugins) the user session is not reset on logout – check for this.
- Rails 2.1 and smaller - Despite the parameterise ability of the ActiveRecord class the limit and offset parameters in the find method where not typecased. This leaves the door open for SQL injections. This was fixed but the MySQL adapter still appears vulnerable.
- Mass assignment (user = User.create(params) can allow for great havoc if the malicious user send extra parameters in the post request that relates for example to the user level. Use attr_protected and attr_accessible
- DOS attacks can be launched against file upload functionalities by sending very big files. Use the web server to handle file uploads or use the web server direct the request to another application to deal with file uploads.
I spoke to the guy afterwards to get an idea on what his opinion is on Rails’ maturity in terms of security. I mentioned a certain ‘trust’ in PHP due to the time it has had to mature. His reply was that Rails has been developed from a much better security perspective than Rails and is more mature to his standards.
Functional Testing Lessons Learned - Jay Fields (DRW Trading)
Jay mainly looked at the following three points:
- The place and role of writing tests
- Comparing different test suites
- Different types of tests
He stressed the importance of testing and the purpose thereof. It is especially applicable in environments where code improvements, refactoring and growth is a constant occurrence. Testing plays a central role in making sure that the result of these actions does not break the code and that breaks in the code can be indentified as soon as possible. From a certain perspective testing is a way to document the functionality and purpose of code.
I picked up on the following statements two statements that I felt creates a great perspective:
- Testing code is just as important as application code.
- Tests should be created that provides a positive return on investment
An important point is that testing does not replace the need for manual testing – it does not replace a QA team or a testing team. Automated tests might test the intended functionality but the perspective from a person that is not involved in the development is needed.
The Rails framework encourages two testing approaches – Unit testing and Functional testing. Unit testing has to do with testing classes in isolation by simulating the functionality of dependencies to the outside of the class. Functional testing has to do with testing functionalities that is presented by the integration of different units. Have a look at his blog entry http://blog.jayfields.com/2007/09/rails-how-we-test.html for more thoughts on this.
Other test types include integration tests, smoke tests, use case tests and automated browsers tests. I’ll leave it up to the reader to investigate these further.
Three testing suites were discussed:
- RSpec
- test/unit
- Selenium
The factors to take into account when choosing a test suite are:
- Ease and simplicity of implementation
- Flexibility to support the different types of tests
- Ability to present the test code to non-technical project members – QA team, senior management etc.
With these factors taken into account RSpec was considered the best option with test/unit in second and Selenium very unfavourable.
To bring the security aspect into this topic – I wonder if there is a case for security consultants to assist client developers in writing test cases for there applications that will also assist the developers in keeping a security perspective on there code.
Small Things, Loosely Joined and Written Fast - Justin Gehtland (Relevance, Inc.)
I think this was the best talk that I attended. Unfortunately for the reader of this article it was really one of those talks that you have had to been there. The slides was mainly a few photos to support his comical metaphors, my notes practically non-existent and an excellent demo that you’ll have to go though the code in your own time.
The main argument was – Big problems do not require big solutions bundled in one big fat application. Proper solutions consist of a number of small independent applications that can be developed, configured, tested and managed independently. These smaller solutions then be integrated together to tackle the big problem.
To use his terms – This approach will improve your productivity by improving:
- Testability
- Compose-ability
- Security
- Scalability
And, to quote him “Make small things, join them loosely, write them fast, scale them independently”
He had a wonderful demonstration on three Rails applications that are delivered through a single entry point using a central authentication point and a message queue for some of the communication between the independent parts.
Have a look at his blog entry - http://blog.thinkrelevance.com/2008/9/3/small-things-loosely-joined-written-fast
From Rails Security to Application Security - Carsten Bormann (Universität Bremen, TZI), Steffen Bartsch (TZI, Universität Bremen)
I am not going to attempt to cover this talk in too much depth. They touched on the topics of:
- Data confidentiality, integrity and authentication
- Threat matrixes
- Attack trees
There is loads of information out there on this that makes covering the topics in this write-up irrelevant.
The one thing to take note of in this talk is an authorisation plugin that Steffen developed. It offers a very clean way to manage authorisation of access for different level users to all the levels of the MVC architecture. Despite offering great flexibility and full management of authorisation it has very clean way of presenting the authorisation rules to the developer, making the auditing of the rules a very easy process.
See the presentation slides on Steffen’s blog - http://steffenbartsch.com/blog/2008/09/from-rails-security-to-application-security/
Writing resources_controller: Discovering REST Patterns in Rails - Ian White (Argument from Design)
REST is getting great attention in the Rails community, in fact I will dare to say - I think the RAILS community are leaders in the RESTful approach. If I may quote Ralf Wirdemann and Thomas Baustert from RESTful Rails Development (http://media.quilime.com/files/pdf/restful_rails_en.pdf) “REST describes an architecture paradigm for web applications that request and manipulate web resources using the standard HTTP methods GET, POST, PUT and DELETE.”. In other words - A resource (data object/model) is mapped to a URL and is managed by the standard HTTP methods.
Also and as mention earlier, Ruby programmers support DRY (Don’t Repeat Yourself) code.
Ian developed a plugin (seems like if you want to talk at Rails conference then you have to write a plugin) that provides a central Resource Controller that can manage the REST functionalities of all your other controllers. For a very thorough explanation of this see the blog - http://blog.ardes.com/resources_controller
