Today, we upgraded our Portal and back-end services which run on Rails to the latest production point release, 3.2.11. This was an emergency upgrade due to recent vulnerabilities that have been found in the product. The fixes were straightforward, but dealing with the upgrade showed us some areas where legacy code was holding us back.

We ran Rails 1.2 far longer than we should have with our old Portal, but were focused on product enhancements and features that were unrelated to the rails version. In 2012, we upgraded to 3.1, but had some old dependencies on ActionWebService. We use web service calls to communicate internally between the server running Portal and the servers running your repositories for things like modifying Subversion permissions or trac.ini files.


We were using the dnordberg fork of ActionWebService to Rails 3.x, but with the upgrade to 3.2, the port was at risk of causing issues. The methods in question were remote procedure call, and while some of them could possibly have been ported to RESTful operations, we wanted to do the minimal changes required to support the existing framework.

We ultimately did the changes in 3 steps:

1. Modify the server-side controllers to accept parameters and return JSON instead of returning a scalar or object using render :text.
2. Create a client with the same interface as the one defined in the API spec.
3. Remove references to ActionWebService.

We used HTTParty to do the GETs and POSTs. To our delight, after we swapped out the transport mechanism, we found that the calls worked without further modification in most cases. Of course, fewer changes means less chance of introducing new bugs.

We’re now on 3.2 and subsequent Rails upgrades should be easier. Due to the above changes, there may still be a couple of kinks here and there, so just open a ticket if you run into a problem that gets in your way. We know that some people ran into some problems with accessing certain pages today, and we apologize for that, but due to the seriousness of the vulnerabilities, we didn’t want to wait one second more than we had to to verify the stability of the code.

Please feel free to drop us an email or reach us via ticket if you have any questions as well about what we’re doing or recommendations for improvement.