Play with MongoDB

For the normal data storage in most of todays applications a relational DB is not the optimal solution for several reasons. There are many great alternatives now on the market. I like MongoDb because it is not that far away from the concepts of a relational DB, it is easy to set up and has proven to be stable and reliable.

Thus I clearly want a MongoDb as persistence in my Play 2! project. Goal is

  • to have a good abstraction. Not too much magic but not too much boilerplate either
  • to have it running locally and in the cloud (I’ll go for Heroku here)

I found Salat a pretty good abstraction. It got it running quickly locally. But when I tried to get it running on Heroku it became a little awkward. At Heroku – as on every other PaaS I had a look at – you get a URL for the MongoDb you added to your app, normally provided as system property. Same holds if rent a DB in the cloud at a “pure” cloud DB provider. But there are no means (that I know of course) to easily let Salat read and use the URL.

So I wrote a MongoDao that does the following things:

  • it reads a MongoURL defined in the application.conf via the mongo.uri property.

In my template application I provided an example that reads the environment variable MONGOLAB_URI which is the system variable on a Heroku app with an installed MongoLab instance. If no such variable is set, the property is left empty. This lets the MongoDao take the standard parameters for a local MongoDb installation.

  • a collection method that returns a collection as required by the SalatDao, so you can easily define the SalatDao in your implementation
  • if you want to differentiate between different local DBs you can overwrite the defaultDbName val in you class.

This is pretty much it. If any one of you has good ideas to make the abstraction more convenient, clean, elegant I’d be happy to read your comments.

Basic authentication with Play! 2

I recently had the problem that I wanted to secure a page preview we developed with basic authentication. Easy thing I thought. But it wasn’t. I was used to the use of frameworks/containers like tomcat, which provide easy means to do such things. With Play! though you don’t have such things. You’ll have to do it yourself.

The good thing is that you’ll understand what is actually going on:

The basic stuff happening is:

  1. Request for a certain page is sent to the server
  2. On the server the header with the name “Authorization” is looked up
  3. If it exists the contained string is parsed. It’s in the format “name:pwd”. Then name and pwd are checked.
  4. If either the header does not exist or nam/pwd are incorrect an unauthorized 401 response with a header of name “WWW-Authenticate” and a content that must contain the word basic is sent. This lets the browser know what actually to do.

Thats pretty much it. With Play! 1 this was pretty easy as you had direct access to the response as you might be used to in several MVC frameworks. With Play! 2 this is not so obvious although also really easy:

You can add a header to the response by using the method withHeaders. A good example can be found here.

At the time I needed it, I was unable to find an example in the net. Now as I wanted to finish this post and made another quick query and immediately found the example of Guillaume Bort. As he develops the play framework I decided to just add the link here without any code.