01 July, 2014 by Denise << programming, scala, play-framework >>

CORS and (Scala) Play

What is CORS?

CORS stands for 'Cross Origin Resource Sharing'. It's a way for a website to access resources (e.g. via AJAX calls) that are not on the same domain. This includes the case where only the ports are different, i.e. http://localhost:1111 is not considered to be the same domain as http://localhost:2222. These sorts of requests are forbidden by browsers because of the same origin security policy.

When might you need to deal with CORS?

You'll often need to work around CORS when you have an API serving JSON which you want to call from your fancy Javascript MV* framework application. You might deploy your back end to Heroku or AWS and have your front end code deployed to Cloudfront and serve it from a custom domain. If your back end code doesn't implement CORS then you'll get an HTTP error when your front end tries to call it.

Writing a CORS filter in Play

To implement CORS in the Play Framework, you'll need to create a filter. Mine looks like this, and you can see that all it really does is set a bunch of headers:

package filters

import play.api.mvc._
import scala.concurrent.ExecutionContext.Implicits.global

class CorsFilter extends EssentialFilter {
  def apply(next: EssentialAction) = new EssentialAction {
    def apply(requestHeader: RequestHeader) = {
      next(requestHeader).map { result =>
        result.withHeaders("Access-Control-Allow-Origin" -> "*",
          "Access-Control-Expose-Headers" -> "WWW-Authenticate, Server-Authorization",
          "Access-Control-Allow-Methods" -> "POST, GET, OPTIONS, PUT, DELETE",
          "Access-Control-Allow-Headers" -> "x-requested-with,content-type,Cache-Control,Pragma,Date")
      }
    }
  }
}

You will also need to reference this filter in your Global.scala class, which you might need to create if it doesn't already exist in your application. Mine looks like this:

import filters.CorsFilter
import play.api.GlobalSettings
import play.api.mvc.WithFilters

object Global extends WithFilters(new CorsFilter) with GlobalSettings

Gotchas

At one point I had an issue where my filter wasn't being executed, no matter what I did, I hooked up the debugger and stepped through the code but for some reason the filter code was never executed. Eventually, I found out that the Global.scala class must be in the default package in your Play application - I had put mine in its own utils package which was why it was never being called.

There is also something that browsers do for more complex requests (like a POST with a MIME type of application/json which is pretty common in these RESTful API style applications) which is called a 'pre-flight request'. This is basically where the browser checks to see whether it is allowed to make the request before performing the full request. It does this by sending an HTTP OPTIONS request, and is something you will also need to handle. The way I did this was to define an additional route in my routes file like this:

OPTIONS        /*all                                            controllers.Application.preflight(all: String)

which is implemented like so in my controller:

  def preflight(all: String) = Action {
    Ok("").withHeaders("Access-Control-Allow-Origin" -> "*",
      "Allow" -> "*",
      "Access-Control-Allow-Methods" -> "POST, GET, PUT, DELETE, OPTIONS",
      "Access-Control-Allow-Headers" -> "Origin, X-Requested-With, Content-Type, Accept, Referrer, User-Agent");
  }

Summary

Implementing CORS is often painful and more time consuming than it really should be, so I hope this can help someone else out. Perhaps I should write a Play framework module so this code doesn't have to be re-written every time someone needs to add CORS to their app!

Update

I've created a Play module to implement the above CORS functionality. It's been published to Maven Central. If you have any ideas for improvements or find a bug, please feel free to raise a Github issue or send a pull request through!

Github repo is here: https://github.com/rowdyrabbit/play-cors

Artifact in Maven Central:
http://mvnrepository.com/artifact/be.cafeba/play-cors_2.11/1.0

10 June, 2014 by Denise << programming >>

Idempotence, REST and Caching

What is Idempotence and 'safety'?

Idempotence means the result will never be changed, you can keep calling the method, but the response you get back will always be the same. It is possible that something is being changed on the server, but the result not changing is what defined something to be idempotent.

Safety is where the resource on the server is not changed in any way. Things might happen on the server, but the resource itself is not modified. Consequently, the result is never changed either.

The set of safe HTTP methods is a subset of the idempotent methods.

Idempotent HTTP methods

OPTIONS, GET, HEAD, PUT, DELETE

Safe HTTP methods

OPTIONS, GET, HEAD

Browser/Proxy/Gateway Caching

Caching of an HTTP response may occur in a number of different places - it could be within the browser itself, in a proxy server or on a gateway server (also known as a reverse proxy cache).

Caching can only occur for the safe HTTP methods OPTIONS, GET and HEAD. To prevent this (or to have control over it) we need to play with the HTTP response headers.

Cache Expiration (cache-control: max-age=n or expires)

Cache expiration headers will prevent the cache from making the same request until the cached version reaches its expiration time and becomes "stale". If both the cache-control and expires headers are set then on most modern systems the cache-control will take precendence.

Cache Validation (last-modified and etag)

These are called 'cache validator' headers because they are used to validate the freshness of the stored response in the cache, without requiring your backend system to generate or transmit the response body.

A 304 Not Modified will be returned if the currently cached response does not differ from the response values returned by the cache validator.

Combining cache expiration and validation

Cache expiration is checked first, then cache validation occurs if the cache entry has expired. If the cache entry hasn't expired, it will return a 200 OK response. If the cache entry has expired but the request is validated as still being fresh then a 304 Not Modified header is returned, and this 304 response will have updated expiration header info.

Resources
https://www.mnot.net/cache_docs/
http://tomayko.com/writings/things-caches-do
http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
http://www.peej.co.uk/articles/http-caching.html
https://redbot.org/ - for cache testing

06 March, 2014 by Denise << programming, thoughts >>

Programming and Curiosity

I came across a quote recently from the well known book 'Code Complete' by Steve McConnell which I really liked (emphasis my own):

"It's no sin to be a beginner or an intermediate. It's no sin to be a competent programmer instead of a leader. The sin is in how long you remain a beginner or intermediate after you know what you have to do to improve".

Always be learning and improving, and stay curious!

17 February, 2014 by Denise << programming, java >>

Boolean comparisons

Ever wondered why people code boolean checks in if statements differently?

Example 1

This is the kind of code that fails silently because true will always be assigned to hungry and will cause the if statement to be true and the conditional code will always execute.

boolean hungry = Utils.isHungry();
if (hungry = true) {
    /* this code will always be executed */
}

Example 2

There is no possibility of an accidental assignment here, and is probably the most readable code.

boolean hungry = Utils.isHungry();
if (hungry) {
    /* make some cookies */
}

Example 3

This is the kind of code I have seen before but wondered why the developer has reversed the comparison. This is a defensive programming style, such that if in the future another developer accidentally changes == to = then the code will not compile because true is not a variable and the value of hungry cannot be assigned to it.

boolean hungry = Utils.isHungry();
if (true == hungry) {
      /* make some cookies */
}

In my opinion Example 2 is the cleanest, but now I at least realise why other developers might choose to use the style of Example 3.