Building Web Applications With NancyFX

Nancy Hosting
When you create a web application, you will need to host it somewhere. You may have a server farm of your own running internet information services, or a hosted IIS virtual server or even an Azure site or other platform as a service host. You might want to run your site on a Linux based server. You may want to run your site as an endpoint for diagnosing and instrumenting a service or desktop application. Because we are using the framework that subscribes to the super duper happy path, running Nancy in any of these environments is very straightforward. By adding the right library it just works, but also allows you to customize the implementation when you have the need.

Nancy Conventions
In this module we will consider some of the conventions that Nancy includes. In the spirit of the super duper happy path, Nancy just works, but allows customization. This means that Nancy will run out of the box without us having to make any decisions about where to place static content, enabling culture logic, where to find views, adding dependency injection, or serializing and de-serializing JSON and XML. The built in conventions can, for the most part, be left as is. We will explore why you may want to enhance or change these defaults. For the first three conventions, you can change the default behavior in the Bootstrapper by overriding the ConfigureConventions method.

Authentication and Security
A common model for enabling authentication in web applications is registration, login, and password management within your application. Another model is enabling an application to use your social media account to verify user's identity, such as using Facebook or Twitter authentication. Many sites that use social medial logins also include an application specific user flow as a backup. Yet another model is an application that leverages single sign-on, that uses a trusted authority outside of a social medial context for authentication. An example of this would be using Active Directory authentication for a company site. Nancy can handle each of these and other situations with existing NuGet packages or custom code. This module is all about that flow. I will show you how to integrate the Nancy forms authentication package and the concepts you will learn here will transfer to other authentication flows. Here's our module checklist. We'll create our security route, that means we'll add sign-in, register, and journal entry views, and create a new module with our route definitions. We'll review the before and after hooks of the forms authentication package. We'll integrate forms authentication by adding that package, configuring the application to use the forms authentication package, and we'll create an InMemoryUserMapper that will utilize until we add the database. We'll review the extension methods that forms authentication adds to help you log in and log out your users. And we'll wire up our sign in, register, and sign out links and buttons. We'll secure our journal entries point. And finally we'll discuss encryption, both cookie encryption and one-way password hashing.

Wrapping Up
We now have a minimum viable product on which we can build additional functionality. We've implemented an authentication workflow, a persistence framework, and a deployment strategy. In order to prepare for additional feature developmental, we need to do a little housecleaning. Our modules have some repeated code that we can move into a base class. We don't do a very good job of indicating that our users are logged in. Landing, register, and sign in pages do not detect whether the user is logged in and therefore do not surface that to the user. Our application could also benefit from localization to ensure that it is available for a diverse user base. And lastly, we will add custom error pages to our application. Once we have completed these tasks, we will close out this course and I will leave you to add additional functionality to this application.