Thursday, October 31, 2013

Instant Nancy Web Development Giveaway


I have 5 ebook copies of my Nancy book to give away in a raffle.
To enter the draw simply share this link - http://www.packtpub.com/nancy-web-development/book - on Twitter or G+ along with the hashtag #InstantNancyFxBook before Thursday the 7th of November when I will draw 5 random winners. I will contact the winners through Twitter or G+ to get the email they want to receive the book at.

In case you're wondering what the book is about here is the appetizer from the publisher's site:

Nancy is a C# web framework which aims to provide you ,the application developer, with an easy path to follow, where things will naturally fall into place and work. Nancy is a powerful, flexible, and lightweight web framework that allows you to get on with your job.

Instant Nancy Web Development will give Readers practical introduction to building, testing, and deploying web applications with Nancy. You will learn how to take full advantage of Nancy to build clean application code, and will see how this code lends itself nicely to test driven development. You will also learn how to hook into Nancy to easily extend the framework.

Instant Nancy Web Development offers you an in-depth exploration of all the major features of the Nancy web framework, from basic routing to deployment in the Cloud, and from model binding to automated tests.

You will learn how to build web applications with Nancy and explore how to build web sites using Razor views. Next, you will learn how to build web based APIs suitable for JavaScript clients, mobile clients, and even desktop applications. In fact, you will learn how to easily combine the two into one.

Finally, you will learn how to leverage Nancy to write clean and maintainable web applications quickly.

Saturday, October 26, 2013

Supporting Single Sign On In Your Nancy Applications

In enterprise application the requirement for single sign on is common: Users are already authenticated against the domain controller - they don't want to jump through another authentication hoop to get access to your particular application. Setting this up in ASP.NET using WIF is some pretty easy web.config gymnastics and described elsewhere. The result of this setup is that the current principal on authenticated requests is a ClaimsPrincipal identifying the user in terms of the claims setup for him/her in the identity provided (e.g. your organizations Active Directory).
Below I show how to integrate the WIF authentication setup with your Nancy application - It doesn't take much, but lets run through it anyway. In fact only 2 small classes are needed. First we define a user type that implements the IUserIndentity interface expected by Nancy, by pulling the necessary information out of the current claims principal:

The second thing we need is set the current user on the NancyContext for each incoming request. We do this by hooking into Nancys request pipeline with a Before hook. We can do this directly in our Nancy applications bootstrapper or in a separate type implementing IApplicationStartup (Nancy automatically finds and executes these at application startup). This is how it's done with the IApplicationStartup approach:

That's it. Now your modules can start using the Context.CurrentUser and take advantage of Nancys authorization helpers.

Update: As kindly pointed out by Damian Hickey this will not work if you host your Nancy application on OWIN. So to be clear: I have only tested this when hosting on ASP.NET. The fact that it will not work on OWIN, means that the approach has the drawback that it leaks knowledge of the host to the application level. Specifically to the SetUser class.

Thursday, October 10, 2013

Why Not Use Custom Visual Studio Project Templates?

I got this question about the Nancy book the other day on twitter:

The answer I gave was just a bit of hand waving in the general direction of the question:

While it is true that, that is my preference, there is not much by way of explanation in that answer, so I'll try to explain a little more here.

Pre-baked project templates are there to help developers out. They are a way to get quickly up and running with a fully setup project. With some of the heftier templates everything is there from dependent assemblies, configuration files, and folder structures to skeleton code. Basically some template provide a full wlaking skeleton. Just like that. Click, click, click, and you're done.
I don't like that as a starting point for a code base. It's too much and the odds of such complete templates fitting just right to the project at hand are in my experience minuscule. So you end up changing the setup that came with the template. This is a battle I don't want to be fighting. Firstly because it will quickly off set any initial gain won by getting quickly up and running using the template, but secondly and more importantly because it is battle against accidental complexity that should never have been there in the first place. This is the wrong way around. We want to start out small and then only build up more stuff as it becomes needed. Not before, and definitely not from the get go. I saw a nice talk on the benefits of this at GOTO last week, the gist of which was how keeping it simple enabled evolving from a very simple - almost simplistic - initial system to a full blown system without loosing speed or ending up with a mess. In fact although not about agile that was the best talk on agile I've seen in a while.

How about smaller templates then? I like them a little better, but only a little. At the end of the day they suffer from the same problems.

How about really small focused templates? Those I can live with because there is so little left that there is a chance that it actually fits my situation, and if not the battle to overcome the template is small.

How do I prefer it then? In fact I'd prefer it if Visual Studio did not require project and solution files, but was able to just run off the build files I wrote - be it rake, psake, nant or even MSBuild. Since this is not the case the next best thing is starting off with an empty project template. That is the minimal amount of initial complexity. Then after that I can add the packages I need. With each of them I add some complexity too, but it is the complexity I've deemed worth while.

Of course there is a lot of gray scale here: When is a template close enough to empty? When does a NuGet package become a complete project template? These are case-by-case judgements that you will have to make for yourself.

Tuesday, October 1, 2013

GOTO Day 2

Yesterday I was somewhat disappointed. Today the GOTO I know and enjoy is back!

The day is not finished, but I can already say I learned stuff today. I went to the two web security talks. For a while now I've gone to the security talks at the conferences I go to and it seems to me that the signal to noise ratio is generally low at these talks. I think that this is to some extend because both speakers and conferences assume that the audience sees security as boring, so they try to make security digestable by disguising it, wrapping it in gags etc. All of which risks to detract from the actual content.
Both the web security talks at GOTO today were well worth going to, though. The first talk by Aaron Bedra was about spotting attacks by looking at the behavior of clients and the second by Niall Merrigan was about defensive programming. Both were good, but I will focus on the first.

Aarons talked about how you can have your web server keep an eye out for suspicious behavior. Suspicious behavior could be a number of things, like a client doing only HTTP POST requests, clients originating from countries that your site is not aimed at or clients making requests that do not look like the requests created by the browser indicated by the user agent. Each of these behaviors are only indicators though, but if a combination of them are present you are likely seeing an attack. Such a combination is a signature.
Taking this a step further Aaron talked about how you can profile clients based on these signatures and identify clients that are likely rogue. Once identified another part of the system can take the appropriate action, which can range from simply rejecting the client with e.g. 403s over just introducing extra hoops to jump through (think CAPTCHA or security questions), to just flagging the the client and store thee information for later analysis.
Lastly Aaron talked a bit about the framework he created for dealing with these sorts of things; RepSheet, which I do hope to find the time to look into some more.

That's it for today except for this: If you're at GOTO tomorrow you must go to Bodil Stokkes talk, otherwise you're doing it wrong :)