Forcing SSL in a Luminus application

We tend to be very security conscious at Carousel Apps and one thing we often do is force all our applications to run over TLS (aka SSL), that is, when you go to http://example.com we redirect you to https://example.com. This little article will show you how to do it in a Luminus application.

First, add Ring SSL to your project by editing project.clj , finding the list of dependencies and adding:

That library provides various Ring middleware functions to deal with SSL. The first one you care about is wrap-ssl-redirect  that will cause an HTTP request to be redirected to the equivalent HTTPS one.

In your middleware.clj  file, find the function wrap-base  which will look something like:

Depending on which options you added, you might have fewer or more middleware functions in your project. You can start simple by adding  wrap-ssl-redirect  to it, like this:

Redirecting to SSL should happen as early as possible to avoid leaking any information over a non-secure channel. With that code you’ll immediately run into trouble when running your project locally, because neither your development environment nor your test one are likely to support TLS, so you’ll get redirected to HTTPS and it won’t work.

That’s easy to solve by creating a function, let’s call it enforce-ssl , that will skip the enforcement when developing or testing:

and then in your middleware configuration:

The function wrap-ssl-redirect obviously checks whether you are already accessing the site over SSL and if that’s the case, it doesn’t redirect you; otherwise you’d have a redirect loop.

If your application is sitting behind a proxy or a load balancer, like in the case of Heroku, Linode’s Load Balance, AWS Elastic Load Balancing, etc. the proxy will be terminating the HTTPS connection and then it’ll issue an HTTP (non-S) connection to your application because since now you are in an internal secure network, encryption is no longer required and HTTP is faster. Thus, your application after forwarding to HTTPS will still receive connections to HTTP and forward again and it’ll be stuck in an infinite forwarding loop.

The convention for this situation is that those proxies will add the header X-Forwarded-Proto with the original protocol, either http  or https. There’s another middleware function called  wrap-forwarded-scheme  that will look at  X-Forwarded-Proto (or another header entry of your choosing) and set that as the actual scheme in the request so a simple check for  http  or https would suffice:

Doing the scheme forwarding should be the first thing you do, so that wrap-ssl-redirect  can use the correct scheme.

IMPORTANT: if your application is not behind a trusted proxy, or the proxy is using a different header, then blindly applying wrap-forwarded-scheme would be dangerous as your application could be easily deceived into believing a connection is secure which would enable a man‐in‐the‐middle attack.

One last thing that we do is add wrap-hsts  which makes sure the browser from now on will only use HTTPS for this domain, even if the user types http (which would result in a redirect anyway). The final code looks like this:

And that’s it, your application now uses TLS/SSL by default, something that you should always consider and definitely do if there’s any kind of auth at all.

Falling in love with Clojure, all over again

Clojure logo

You know when after a few months of dating someone, they do something that touches you and fall in love all over again. It just happened to me and Clojure. I was playing with Korma and I had the following namespace declaration:

which was generating this warning:

What now? I thought I was going to spend the next two hours figuring out a clean way to deal with this, but nope, it took 5 minutes to figure out I could just rename korma.core/update  as I was requiring it:

This is the kind of real world pragmatism that you rarely see in programming languages, specially those rooted in academic practices, like being a Lisp, which Clojure is.

I fell in love all over again. Sometimes it’s the small things you know!

Fixing conflicts

Screenshot of gitk

The more programmers working in the same piece of code, the more conflicts will occur. So fixing conflicts is a common task when programming. Like many other organizations, here at Watu we use git as our version control system. Today I’d like to share a not-so-known tool very useful for properly solving conflicts:

It will show you the commits in conflict from the different branches.

If you did’t know it, try it the next time you have a conflict and tell me how it was.

Carousel Apps coder speaking at PyConAr

Ruby for Python programmers

PyConAr 2014PyConAr is the main Python Conference in Argentina which will happen from the November 13th to 15th in Rafaela, Santa Fe and our very own Juanjo Conti is going to be presenting. If you been following our development blog, you might be wondering how is this possible, since the main language at Carousel Apps is Ruby. All developers at Carousel Apps know many languages and this is a strict requirement to work here, as we don’t hire Ruby coders, we hire coders, amazing coders.

Juanjo has a long history of working in Python, hence his ties to that community, but he’s not going to do a presentation about Python, he’s very brave to present: Ruby for Python Programmers (Ruby para programadores Python). We wish them best of luck and if he needs a body armor, we are happy to provide.

Update: the video of the talk is online (spanish).

Run bundler-audit during testing

There’s a gem called bundler-audit that checks whether any of the gems in your project have open security advisors against them. A year or so ago there was an infamous month in which Rails itself got three of those. It was terrible and I think bundler-audit is a good idea. My only problem with it is having to remember to run it: it just won’t happen. I need to run it automatically and an easy way to do that is to run it as part of my tests.

Unfortunately, bundler-audit doesn’t make it easy. It’s designed for the command line and that’s it, but these days it’s easier than a year ago and I recommend everybody to add them to their integration tests. Here’s how we do it at Watu:

I don’t try to show the vulnerable gems because I found those methods to not be easily reusable and I didn’t want to copy them because they look like they might change at any moment. It’s not a big problem, if something is wrong, you should run bundle-audit check anyway.