Enabling sessions in Nancy

As you may know, AppHarbify is built with Nancy. One of the reasons I decided to build it in Nancy, other than the fact that Nancy is awesome, was that I wanted to put together a real project that can be used as an example of Nancy in action. All the code for AppHarbify is available on GitHub.

To go with that I am planning to put together some blog posts talking about various aspects of the code.

To start with I am looking at sessions.

Getting Started

Nancy ships with a single session provider implemented, CookieBasedSessions. You can of course add your own.

This provider stores the session, encrypted, in the users cookies. Which is really not too bad of a solution to get started. You are up and running with a single line of code added to your ApplicationStartup method in your Bootstrapper.

Once enabled, you can simply access the Session property on Request.

Request.Session["Key"]

Now you don’t want to store too much data in a cookie-based session like this, as every request is sending the data back across the wire. Also it is theoretically possible the encryption could be broken. Side note: You can control the encryption provider with an optional second parameter to .Enable(). If you do not, then a new key is generated each time the app starts, invalidating all existing sessions.

Testing

If you do any work with sessions, you are likely to need to test them eventually. While the mechanism is a bit awkward, it is essentially pretty easy. My preferred method is to attach an event to the .Before pipeline in your testing Bootstrapper that injects the required session into the request.

By adding this simple extension method and calling it on your Bootstrapper whenever you want to test a route that needs session information, you can very simply abstract away your real session storage mechanism without adding more layers of abstraction to your actual codebase.

Future

While AppHarbify is currently running along fine using these cookie based session, for the reasons I have stated above it is not ideal. So the plan is to write Redis based session mechanism and take advantage of the easily installed Redis add-on at AppHarbor. Of course this code will be open-source and released independently of AppHarbify as a nuget package. So watch out for that!

AppHarbify Tools

An important goal of AppHarbify is to make as much open source software as possible be AppHarbor-friendly. To speed this process along I will be creating and/or finding many libraries to solve common problems.

The first problem I have tackled is handling connection strings with Entity Framework. Specifically conventions based Code-First EF.

AppHarbor already has quite an elegant solution where you log into the Sequelizer add-on and set your desired connection string, then at deployment that connection string is either inserted or updated with the connection details for your instance.

Unfortunately AppHarbify can not rely on this mechanism as it can not set configuration variables inside an add-on.

The solution

What I found was a static property Database.DefaultConnectionFactory which holds the factory EF uses to create its database connections.

It was then a simple matter of detecting if we are on AppHarbor (by the presence of the AppSetting which AppHarbor stores the connection string in) and then replacing this factory with a new one that creates connections from the AppSetting.

https://github.com/csainty/AppHarbify.Tools/blob/master/src/AppHarbify.EF/ConnectionFactory.cs

NuGet Package

To make this as simple as possible I then bundled this up as a NuGet package AppHarbify.EF.

Once installed it is a one-liner to enable your application to use the connection string in web.config when not on AppHarbor, and switch across to their AppSetting when you are.

AppHarbify.EF.ConnectionFactory.Enable();

Migrations

There is one little snag with this approach. Migrations. The Migrations package, for reasons I have not yet investigated, chose to use their own mechanism for fetching the connection to the database. One that very strictly follows the convention of a connection string named after your DbContext.

So for Migrations to work, you need to strip the connection string out of your web.config when it is deployed too AppHarbor. With no connection string present it will then fallback through other means of creating the connection and settle on one that works for us. If AppHarbor is your only deployment target, this is simple. See https://github.com/csainty/JabbR/blob/AppHarbify/JabbR/Web.Release.config#L18

If you need to handle multiple deployment locations then this is going to get more tricky. I am hoping that the EF team can unify behind one strategy for database connection creation and make it extensible.

Announcing AppHarbify–Simplifying open source deployment

Since finishing up my day job last week, I have had some time to dedicate to a project idea I had a few months ago. It is now time to formally announce it.

Say hello to AppHarbify!

AppHarbify aims to make deploying common software to AppHarbor even easier. So easy that it can be done by non-technical people or from mobile devices.

The plan is to make as much .NET (or Node.js) open source software as possible compatible with the AppHarbor platform. Then bring it all into the one place and offer single step deployment. You can try it out right now with some of the projects I have used for testing http://appharbify.com/Apps, including JabbR and FunnelWeb.

AppHarbify takes care of creating the application, installing the required add-ons, configuring application variables and deploying the code base. All you need to do is authenticate, via OAuth, with AppHarbor and choose which project to deploy.

In addition to all this deployment goodness, there is a second side to AppHarbify. From the Deployed Sites link you can see a list of all your deployed AppHarbor sites, regardless of whether AppHarbify deployed them, and add useful tools or features. At the moment support is limited to email based build notifications, but there will be plenty more.

This is all made possible thanks to the AppHarbor API.
AppHarbify is open source and on GitHub https://github.com/csainty/Apphbify. See the README for details on how to add new deployable software.
It is written with Nancy and of course hosted at AppHarbor.

If you have any questions, comments or suggestions I am on twitter @csainty and usually somewhere in the JabbR rooms.