Auth0: Introduction and Initial Project Setup

As I started my exploration of Identity Server I listed a few alternatives that provided the same type of functionality, but as a Software as a Service. This series of posts will be covering one of the options I mentioned, Auth0.

The big selling points for Auth0, and other services like it, are that it removes you from having to worry about Auth/User Management and get to the part of your applications that bring value to your customers. As with Identity Server, Auth0 can use OpenID Connect (as well as a lot of other protocols), single sign-on and API Access Control.

Sign-up

The first step in getting started is to sign up for a new account. Here is a link to the sign-up page (not an affiliate link). You can use a username and password or a social login. I’m going the social route using GitHub.

After user creation then there are a couple of setup steps. The first is to choose a tenant domain and region.

Click next and on the second step, there are questions about what the account is going to be used for. In my case, it is a personal, developer, who is just playing around.

Click Create Account to finish the creation of your account which will then land you on the account dashboard page.

Auth0 Setup

Client

From the Auth0 Dashboard click the New Client button. Give the client a name, TestMvc in my case, and select Regular Web Applications as the type.

In a follow-up post I will be covering the Single Page Web Application, but for this post, we are going to be using MVC since it tends to be simpler. The next page defaults to a framework selection which seems to be a guide to getting going for the framework you select. We are going to skip that and click on the Settings tab.

On the settings page, we need to fill in a value for Allowed Callback URLs. The sample client should use  http://localhost:50774/signin-auth0. Click the Save Changes button.

API

While we are doing some setup on the Auth0 site we are going to go ahead and set up our API as well. Click the APIs menu option on the left menu.

Then click the Create API button. In the dialog enter a Name and Identifier and click the Create button.

Sample Solution Structure and Setup

The sample solution for this post has two projects.

  • ApiApp – Backend application and is a resource that is will require authorization to access. The API is an ASP.NET Core Web API.
  • ClientApp – Frontend application that will be requesting authorization. This is an ASP.NET Core application that is hosting an Angular (4) application. Note for this post we will be using MVC and not Angular. A future post will deal with the Angular side.

The sample solution with the two projects already added can be found here. If you are using the sample solution feel free to skip the next two sub-sections as they are going over how the projects were created.

To start, add a directory to contain the solution.

API Application

Inside the solution directory, create an  ApiApp directory. From the command line in the  ApiApp directory run the following command to create a new ASP.NET Core application using the Web API template.

Client Application

Inside the solution directory, create a ClientApp directory. From the command line in the  ClientApp directory run the following command to create a new ASP.NET Core application using the Angular template which as of this writing outputs an Angular 4 application.

After generation is done run the following to make the all the NPM packages that are required get installed.

Solution

Inside the solution directory, let’s create a solution file for use with Visual Studio. Run the following command to create a solution file named  AspNetCoreAngularAuth0.sln.

Next, run the following two commands to add the API and Client projects to the solution.

Securing the API Application

Open the  appsettings.json file and add a section for Auth0. We are going to need to store the Auth0 domain (tenant domain from sign up) and API Identifier (from the creation of the API at Auth0).  The following is the full file from the API project with the new Auth0 section.

Next, in the  ConfigureServices function of the  Startup class add the following to add authentication using the JWT Bearer scheme to the DI system.

In the  Configure function add the following line before  app.UseMvc() to add authentication to the HTTP pipeline for the API application.

The last step in the API for this post is to add a controller that will require authentication. The following is the full code for the  AuthTestController that was added to the  Controllers directory.

Client Application

In the Client Application open the  appsettings.json and add the following setting related to Auth0. This is the full file so the logging section was existing.

If you are going to be checking in your code into a publically accessible source control I recommend you use user secrets instead of  appsettings.json. You can read more about user secrets here.

Next, in the  ConfigureServices function of the  Startup class add the following. I’m not going to go over this code line by line the gist is it is setting up the application to using cookies and Open ID Connect for authentication.

Note that the  OnRedirectToIdentityProvider bit is related to getting access to the API.

In the  Configure function add the following line before  app.UseMvc to add authentication to the HTTP pipeline.

Testing Setup

In order to provide a way to test login, logout, and API access without using the Angular portion of the client app, remember that will be a future post, I add an  AuthTestController to the  Controllers directory with the following.

Sorry for the formatting, but that sample has long of verbose statements. Nothing crazy going on in this file. There is an  Index action that attempts to call the API and then returns a view. The  Login and  Logout functions do what they say and were pull right from the official docs.

The associated  Index.cshtml file was added to the  Views/AuthTest directory with the following.

This view just shows a link to login or logout and shows the results of the API call. It is ugly but is enough to prove the setup is working.

Wrapping Up

Getting up and running was much fast with Auth0 and would be true of any SASS option I’m sure. It also helped that I have more of an idea of what is going on after all the posts I did on Identity Server. Another positive is Auth0 has some great docs. I used the ASP.NET Core and Web API ones a lot to get this sample application up and running.

Next steps are to get this setup running in the Angular client which should be my next post. The finished code for this post can be found here.

 

Vue: Contact Detail

Last week’s post covered adding a Vue project to the ASP.NET Core Basics example solution. This post is going to cover adding a read-only view of a contact’s detail to being the Vue sample a step closer to being in line with the Angular, Aurelia and React samples. The code before any changes can be found here.

Contact Class

The  Contact interface in the  contactlist.ts file should be deleted. Add a  contact.ts file to the  ClientApp/components/contacts/ directory. This will hold the replacement for the interface we just deleted. The full class definition follows.

This class is very simple and will be used later to show how a function call can be used as part of a view.

Contact Service

Since the application will now have two places that need to access the ASP.NET Core API lets to refactor the API access into a service. This is the same style used by the Aurelia, Angular and React applications. Add a  contactService.ts file to the  contacts directory. The service will provide functions to get all contacts or a single contact an ID. The following is the full class.

Now the API access in the  ContactListComponent can be refactored to use the service. First, add imports for contact and service.

Next, replace the fetch call with a service call.

Contact Detail Component

Add a  contactDetail.ts which will be the backing component for the contact detail view. The following is the full class. Pretty much all it is doing is using get contact service to get contact detail by ID when it is mounted.

Now add a  contactDetail.vue.html file for the UI bits of the contact detail. This is basically just HTML with the same binding syntax as before. Notice that the binding of address is a function call. The other Vue things to note are that the details will only show if contact is truthy using the v-if.

Routing with a Parameter

Finding the proper way to route with at parameter in Vue was not easy. The way it is done has evolved over time making find the right way a little challenging. The first step is to add a route for the contact detail by adding a new item to the  routes array in the  boot.ts file.

The  :id in the path denotes a parameter. The  props: true bit is also key to getting the ID when in the contact detail component. The  contactlist.vue.html needs to be updated to link to the contact detail route.

Finally, in the  ContactDetailComponent we need to use the ID. To do so we need an import to allow the use of the Prop decorator.

Now all that is needed is to apply the decorator to a property of the class that matches the name of the parameter in the route.

Now the ID can be used to get the proper contact from the contact service. The following is code that was already shown, but the full context of how the prop decorator is used is important so I am repeating it here.

Wrapping Up

This brings the projects one step closer to being on the same level feature-wise. Look for one more post to get the Vue project features lined up with the other samples in the solution.

Keep in mind that this is my first look at Vue and my examples may or may not be idiomatic.

The code in a finished state can be found here.

ASP.NET Core Basics: Vue with an API

In the past, I have done some exploration on AureliaAngular and React via the ASP.NET Core Basics series. This post is going to take a similar approach using Vue. The code for the project will be in the same repo as the previous basics examples and will be utilizing the same API to pull data. The code before adding the Vue project can be found here.

Project Creation

There is not a template for Vue built into Visual Studio, but there is a set of templates that can be used via the .NET CLI with the  dotnet new that includes Vue (as well as Aurelia and Knockout). A full list of available templates can be found here. The template we need is Microsoft.AspNetCore.SpaTemplates and can be installed using the following command from a command prompt.

Create a Vue folder at the same level as the other projects, for the samples this would be in the  src folder. In the command prompt navigate to the  src/Vue/ directory. Run the following command to create the Vue project.

After the project generation completes run the following to get the needed npm packages installed.

The last step is to get the new project added to the existing solution. Navigate the command prompt to your solution file. For the sample project, this is the root of the repo. Then run the following command (this could also be done through Visual Studio instead of using the CLI).

Adding the Contact List

In the  ClientApp/components directory add a new  contacts directory to house all the awesome contact related functionality we will be adding. Next, add a new  contactlist.ts. To this new file add the interface which defines what a Contact looks like.

Above the contact interface, add the following imports needed to create a Vue component.

Finally, add the contact list component. This component maintains a list of contacts which gets filled from our existing API when the component is mounted (see the docs for more information on Vue’s lifecycle hooks).

The following if the full component just to provide full context.

Next up is the UI for this contact list component. In the same directory add  contactlist.vue.html.  The following is the full file.

All of the above is pretty straightforward. All the Vue specific items have a  v- prefix.

Add the Contact List to Navigation

The last bit needed to have a working contact list is adding it to navigation so the user can get to the list. The routes are defined in the  boot.ts file in the  routes array. Add the following line to the array to handle our contact list.

Now that the router knows to handle the contact list it needs to be added to the navigation UI. Open the  /navmenu/navmenu.vue.html file and find the unordered list that is the navigation menu. Add a new list item to provide a link to the contact list.

Wrapping Up

Vue reminds me a lot of Aurelia in its simplicity so far which is awesome. Look for the same progression of posts for Vue that happened with React over the last few weeks.

The code in its final state can be found here.

React: Form for Contact Add

Last week’s post covered adding a read-only view of a contact’s details. As before the goal is to get the React project’s features in line with the Aurelia and Angular samples. This week we will be adding a form to all addition of a new contact. The code before any changes can be found here.

Contact List

On the contact list page, we need to add a link to create a contact. This will be added just after the header in the  ContactList.tsx file.

Routing

In order to stay in line with the other sample, the  ContactDetail component is going to be handling both the read-only view and the view to add a contact. This means the ID that is currently part of the contact detail needs to be optional. The following is the change to make ID optional by adding a question mark.

Contact Service

In the  ContactService class, we need to add a  save function. This new function will make a post request to the contacts API and return the new contact with the ID from the API to the caller.

Contact Detail

The  ContactDetail class is where most of the changes are. I had some trouble getting React’s forms to work directly with the instance of the contact class and ended up just storing the parts of a contact directly in state instead of as an object. I expect this is a failure on my part and not an issue with React. I may revisit this in the future. Below is the new structure of the state used by contact details.

Next, the  constructor needed to be changed to handle the new state structure and to handle being called without an ID.

Again, this is way more code than it would be the contact class were being used. Next, the render function needs to be adjusted to render the UI for the read-only view or the contact creation. The decision is based on the ID being set or undefined.

The render of an existing contact needs to be changed to use state instead of an instance of a contact.

The following is the render of the add contact UI. I will call out a couple of parts after. The bulk of the code is just rending of the form.

The following is the input for the contact’s name.

Since I decided to go with the controlled component route React will be responsible for being the source of truth, not the form its self. To accomplish this it is important that the input has a  name and an  onChange event handler set up. The following is the  handleChange function which uses the name from the on change event to update the proper property in the component’s state.

The following line is the reset button which will reset the state to blank out all the fields in the form.

<button className="btn btn-danger btn-lg" onClick={() => this.reset()}>Reset</button>

The  reset function just uses  setState to blank out all the fields.

Not surprisingly the submit button triggers a submit of the form. What happens on submit is defined in the opening form tag.

The  handleSubmit function takes the contact information in state and uses it to create a new instance of a  Contact which is then passed to the  ContactService to be saved. The service returns a new contact object from the server and the ID is stored to state.

If the server does return an ID for the new contact then the  redirect is set to true. Then will case the following code to run in  renderNewContact which will redirect the user back to the read-only view of the new contact.

Wrapping Up

This pretty much gets the React application in line with the Aurelia and Angular sample applications. It has been fun getting a handle on the very, very basics of React. While I am back in the basics sample projects I may go ahead and tackle a Vue sample next.

The finished code can be found here.

React: Contact Detail

Last week’s post covered adding a React project to the ASP.NET Core Basics solution. As I stated last week the goal is to get the React project’s features in line with the Aurelia and Angular samples. This week we will be adding a read-only view of a contact’s details. The code before any changes can be found here.

Contact Class

The  Contact interface in the  ContactList.tsx should be deleted and in its please we will add a  Contact class. As part of this change, I also moved the contact related items to a contact directory. Add a  contact.ts file to the  ClientApp/components/contacts/ directory with the following contents.

This class is very simple and will be used later to show how a function call can be used as part of rendering.

Contact Service

Since the application will now have two places that need to access the ASP.NET Core API I decided to refactor the API access behind a service. This is the same style used by the Aurelia and Angular applications. Add a  contactService.ts file to the  Contacts directory. The service will provide functions to get all contacts or a single contact using its ID. The following is the full class.

The final step in this refactor is to use the new service in the  ContactList class. First, add imports for the service and  Contact class.

Then, replace the fetch call with the service.

Contact Detail Component

Add a  ContactDetail.tsx file which will be used to show the details of a contact including using the  getAddress function of the  Contact class. The following is the full contents of the file.

This is all very similar to the things I have covered before. Now that we have a contact detail component we need a way to display it.

Routing with a Parameter

Import the contact detail in the  route.tsx file.

Next, add a route path for contact detail that expects an ID.

Back in the  ContactList component change the ID to be a link to the new contact detail route using the ID of the contact.

The code for pulling the route parameter was in the  ContactDetail component above, but I am going to show it again just so all the route with parameter information is together. The route parameters can be accessed using  props.match.params.{parameter name} which in this case ends up being  props.match.params.id. The following is the constructor of the  ContactDetail component which is using a route parameter.

Wrapping Up

This brings the projects one step closer to being on the same level feature-wise. I expect at least one more post to get the project features lined up so make sure and keep a lookout for the next post.

Keep in mind that this is my first look at React and my examples may or may not be idiomatic. So far I am really enjoying working with React.

The code in a finished state can be found here.

ASP.NET Core Basics: React with an API

In the past, I have done some exploration on Aurelia and Angular via the ASP.NET Core Basics series. This post is going to take a similar approach as I start doing some exploration with React. The code for the project will be in the same repo as the previous basics examples and will be utilizing the same API to pull data. The code before adding the React project can be found here.

This post is going to cover adding a React project to the existing using the React template that is now built into Visual Studio. The same thing can be accomplished using the .NET CLI so don’t feel like Visual Studio is required. The goal for the React project in this initial post will be to connect to the contacts API and download a list of contacts and render that to the screen. In future posts, I hope to expand this functionality to match that of the Aurelia and Angular projects.

Project Creation

Right-click and select Add > New Project.

In the Add New Project dialog select the ASP.NET Core Web Application. In the case of the sample, the project will be named React. Click OK to continue.

On the next screen make sure and select ASP.NET Core 2.0 and the React.js template. Then click OK.

The following is the resulting React project in the context of the full solution.

Next, make sure and run npm install from a command prompt in the React project’s directory to ensure all the npm packages get restored.

Adding the Contact List

Inside the  ClientApp/components/ directory add a file name  ContactList.tsx. TSX is the TypeScript version of the React JSX file type. The official docs on JSX can be found here. Since this is my first time working with React I took the  FetchData.tsx file and copied the contents and used that as the starting point for my contact list. To lead with there is an interface for what should define a contact.

Next, we have an interface for the state of this component with contains a loading flag and an array of contacts.

In the constructor for the component is where the data is pulled from the API using  fetch. The data from the API is then saved to the state of the component using the  setState function.

Next, the component has a function named  renderContactsTable which takes an array of contacts and returns how they should be rendered. In this case, the contacts are rendered to a table that displays the contact ID and Name.

Finally, there is the render function. As you can guess this is what gets called to render the component. In this case, either “Loading” or the contact list gets displayed depending on if the contact list data has been loaded or not.

The following is the full file for reference.

Add Contact List to Navigation

Now that we have the contact list component it needs to be added to the navigation menu. The first step is to add it to the application’s router. This can be found in the  routes.tsx file. The file is short so I am going to include the full content. Lines 7 and 13 are the ones added to handle our contact list.

The last change is to add a navigation link to the  NavMenu found in the  NavMenu.tsx file. As I am sure most of us are used to adding an item to the nav menu is just adding a new li, but with the React specific  NavLink bit.

Wrapping Up

React is different than both Aurelia and Angular. Don’t take that as a good or bad thing. I don’t plan to pick on a side on the Angular vs React debate I just want to get a good feel for the different frameworks. So far the React experience has been pretty nice and I look forward to doing more exploration.

You can find the finished code for this post here.

Swagger and Swashbuckle: Disable Try It Out

In last week’s post, I walked through adding Swagger support to an ASP.NET Core 2 API using the Swashbuckle. One of the awesome things about Swashbuckle is it provides an integration with swagger-ui.

Try it out!

One of the features of the UI integration is the ability to invoke an end point using the “Try it out!” button. This feature is awesome during development but may not be something you want to allow, depending on the use case, for a production end point.

Disable Try it out!

I tried googling lots of different things to find the option to disable the “Try it out” button and had a really hard time finding an answer. It didn’t help that I want the button text to be “Try it now” for some reason. Thankfully it truly was a failure on my part and there is a provided way to disable “Try it out” and it is much more flex able than what I was initially looking for.

In the  Configure function of the  Startup class find the call to  app.UseSwaggerUI. Adding  c.SupportedSubmitMethods(new string[] {}); will completely disable “Try it out”. The following is the full call to  app.UseSwaggerUI just to provide context.

The great thing about the way this is set up if you can allow some actions and not others. For example, say you wanted to allow get actions but disable the rest. The following would allow for that.

One word of caution the above is case sensitive and if you use  Get instead of  get “Try it out” will remain disabled.

Swagger and Swashbuckle with ASP.NET Core 2

This post is going to be very similar to a post from last December which can be found here. A lot has changed since then and this post is going to add Swagger to an existing ASP.NET Core application using Swashbuckle much like the one from last year. The starting point of the code can be found here.

What is Swagger?

Swagger is a specification used to document an API. As I am sure we all know API documentation tends to get out of date fast and a lot of times is a low priority.  Swagger aims to help solve that problem using a format that is both human and machine readable which can be maintained in either JSON or YAML. The documentation can be auto generated using a tool like Swashbuckle which provides away to keep your consumers up to date. Check out this post by the Swagger team for the full introduction.

What is Swashbuckle?

Swashbuckle provides auto generation of Swagger 2.0, a UI, etc. The project takes all the pain out of getting going with Swagger as well as providing tools and hooks for using and customizing Swagger related items. The full description can be found here.

Adding Swashbuckle

Using your favorite method of NuGet interaction, add the  Swashbuckle.AspNetCore NuGet package to your project. Personally, I have gotten where I edit the csproj file to add new packages. If that is your style you would need to add the following package reference.

This one package provides all the functionality we will need.

Wiring up Swashbuckle

Now that the Swashbuckle package is installed, there are a few changes that are needed in the  Startup class to get everything wired up. First, in the  ConfigureServices function, the Swagger generator needs to be added to DI.

AddSwaggerGen allows for configuration of options, but here we are just setting a name and a minimal amount of information.

In the  Configure function Swagger needs to be added to the request pipeline in order to expose the Swagger generated data. I placed this after  UseMvc.

At this point, the Swagger generated JSON would be available at  {yourBaseUrl}/swagger/v1/swagger.json. To take a step further let’s expose the UI that comes with Swashbuckle. Add the following just below  app.UseSwagger().

Now a UI based on your API is available at  {yourBaseUrl}/swagger with zero extra work on your part. The following is the UI for the post contact route in the example project.

As you can see the UI provides a great view of your API as well as ways to try it out and the potential responses that should be expected from a call.

Controller Considerations

All of this wonderful functionality doesn’t come for free of course. In order for Swashbuckle to pick up your routes, your controller will need to use attribute based routing instead of depending on convention based routing.

In order for Swashbuckle to know the return types and of your controller actions may need to have some attributes added. This won’t be required if your action return a specific type, but if you are returning an  IActionResult you should attribute your action with all the  ProducesResponseType you need to cover the results of your action. For example, the following is the action definition for the Post in the screen shot above.

Wrapping up

Swashbuckle makes it easy to add Swagger to a project. I feel that it also provides a huge value for anyone trying to consume an API. It is of course not a magic bullet and communication with your API consumers about API changes will still be critical.

Microsoft’s docs have a great walk through which can be found here. It does more in-depth on customizing your setup and as far as modifying the look of the UI. I also recommend checking out the GitHub page for the project which can be found here.

The finished code can be found here.

Identity Server: Introduction

In the SPA based sample applications, this blog has used so far user authentication has either been completely ignored in order to keep the examples simpler or the sites have used ASP.NET Core’s built in identity to encapsulate the whole SPA. In this post (or series of posts) I am going to share what I learn along the way of creating an Angular (2+) application that utilizes ASP.NET Core as its host/API/backend.

This post isn’t going to cover any code it is just going to be a lot of the information I gathered in the process of learning more about Identity Server.

Following are all the post in this series.

Identity Server: Introduction (this post)
Identity Server: Sample Exploration and Initial Project Setup
Identity Server: Interactive Login using MVC
Identity Server: From Implicit to Hybrid Flow
Identity Server: Using ASP.NET Core Identity
Identity Server: Using Entity Framework Core for Configuration Data
Identity Server: Usage from Angular

Identity Server

According to their docs IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core which enables Authentication as a Service, Single Sign-on, API Access Control and a Federation Gateway.

Obviously, that covers a lot of scenarios. The two that I am interested in are Authentication as a Service and the API Access Control which has driven my research which means that the other aspects of IdentityServer4 will not be included.

Official Samples

The IdentityServer GitHub account has a samples repo that contains a ton of examples. I have found the quickstart area of the repo to be the most helpful when starting out.

Based on all the quickstarts samples it looks like a typical setup involves a minimum of three projects. One for the API, one for the client and one for Identity Server. As you go through the samples the number of projects increase, but that is because of a wider range of scenarios that the sample is trying to cover.

References for learning

Damienbod has a whole series of blog posts related to IdentityServer4 and code to go along with it which can be found here. As a side note if you are interested in ASP.NET Core and you aren’t following damienbo you should be he has a ton of great content.

Blog posts
Videos

Identity Server Alternatives

Identity Server isn’t the only way to go there is a number of Software as a Service options that cover a lot of same scenarios. The following are some examples.

Auth0 – Check out the .NET Core related blogs by Jerrie Pelser
Stormpath
Amazon Cognito

Wrapping up

Obviously, I didn’t get a lot covered on how to actually do something with IdentityServer, but I wanted to share my starting point. This is an area I am going to continue digging it to and sharing information about as I learn more.

If you have any resources in this area please leave a comment below.

Angular 2 Contact Creation and Post to an API

Expanding on this post which created a placeholder for creating new contacts this post will create an actual UI and post the newly created contact to an ASP.NET Core API. The code before any changes can be pulled using this release tag. Keep in mind all changes in this post take place in the Angular project if you are using the associated sample.

Contact service changes to all post

The contract service found in the  contact.service.ts file of the  ClientApp/app/components/contacts/ directory is used to encapsulate interaction with the associated ASP.NET Core API and prevent access to Angular’s Http library from being spread across the application. The first change is to expand the existing import of Angular’s Http library to include  Headers and  RequestOptions.

Next, a  save is added that makes a post request to the ASP.NET Core API with the body set to a JSON version of the contact to be added.

The API will return the created contact with the ID now filled in which will be returned to the caller. As I have said before catching the error and just writing it to the console isn’t the proper way to handle errors and this should be done in a different manner for a production application.

Contact detail view model

The view model that backs the contact detail view needed a function to allow saving of a contact. The following code uses the contact service to save a contact and then replace its local contact with the new one returned from the API. Finally, the class level variable indicating if the view model is in create or detail mode is set to true which triggers the UI to change out of create mode.

You will see in the sample code that a second function was added for  reset which is a quick way to reset the create UI.

Contact model

The constructor of the  contact class changed to make the data parameter optional to allow for the creation of an empty contact.

Include Angular Forms

For the two-way binding needed on the contact detail page Angular forms will be used. To include them in the project open the  app.module.ts file in the  ClientApp/app/ directory. Add the following import.

Then add  FormsModule to the  imports array.

Contact detail view

The following is the full contact view as it stands with all of the needed changes made. This will be followed by call outs of some of the important items.

All control of content rendering has been changed to use  hasContactId.

For the creation UI, the data is bound using Angular’s ngModel binding.

If you have any issues make sure and check that you have the  name attribute set to the property you are wanting to bind to.

The last thing to point out is the click handlers that are used to call the associate save and rest functions with the Save and Reset buttons are clicked.

Wrapping up

Now the application has the ability to add contact not just view them which is one step closer to what would be needed for a real application. The finished code can be found here.