3.1 Start the Project

Now that we have an understanding of webhooks and how GitHub is going to supply the information to our application, we actually need to write our application. And we're going to start by creating a new project. Now how we create our project is going to be different based upon if we are using Visual Studio or if you are using code. For Visual Studio just click on New Project, choose Web and then ASP.NET Web Application and then name the project. I'm going to call it GitPowered but you can call it whatever you want. Click on okay and then you would want to choose one of the ASP.NET 5 templates. Now unfortunately it's rather limited. We have Empty, Web API and Web Application. Now, for our purposes, web application is what we need because this is going to give us all of the things that we need, the MVC framework and a variety of other things, but it's also going to give us things that we don't need, like identity. Now if you are using code, then you would use Yeoman to create your project and there are a variety of different templates that you can choose from. One of those is a basic web application and that is the one that you want to go with because it gives you the basic stuff that you need without all the extra stuff like identity. So, let's create our application. And then Visual Studio is going to create our project. And once it has created the project, it's going to restore all of the packages. So whenever we see the confirmation here, just like that, if we go to Solution Explorer, then we can see that it is restoring packages. And this can take a few seconds or a minute or so, based upon your machine. But here it is done. And if you want to, you can go ahead and run the application. It's going to fire up the browser. And then you can ensure that ASP.NET 5 is properly installed because if it's not, well then you're going to have some issues then. Here we can see that the application is running just fine so we know that ASP.NET 5 is properly installed. And you can also go to Solution Explorer, go to References, and then you can expand DNX 4.5.1 Or DNX Core 5.0, and you can look at the packages because they have the version numbers next to them. And the first one is for Entity Framework, and that's not really going to help us. But if we look on down like at Microsoft.AspNet.Mvc and we can see that it is version 6, because that is the latest version of the MVC framework, and we can also see that it is rc1-final. So we want to ensure that we are using at least the release candidate. Hopefully we would be using the final build. So we have our project ready to go. The next thing we need to do is actually create our controller for our webhook. So let's right click on Controllers, and if you go to Add and Controller, we're going to have a rather limited choice here. We can create an API Controller with actions using Entity Framework or an MVC 6 Controller with views using Entity Framework. We're not using Entity Framework here, so really either of these options aren't what we want. And hopefully with the final build we will have some more options there. So instead we're going to add a new item. And then, we are going to choose either an MVC Controller, or a Web API Controller. Now, in MVC 6, Microsoft has taken the MVC Framework Web API and web pages and combined them all into one. So, now, a controller is a controller. It doesn't matter if it's an MVC controller or a web API. They both inherit from the same class, but they do serve different purposes. For example, an MVC controller is there for returning a view. So typically a client, which is usually a browser, is going to make a request. The controller does whatever it needs to do, sends data to the view. And then returns the view back to the browser so that that view can be displayed. And that's not really what we need. GitHub is going to make a request to our application, but it doesn't care what we send back. So really, The Web API controller is a better fit in our case, because all we would be returning is an HTTP status. So as far as the name of this controller, we want to be as specific as possible, because we could eventually have other webhooks for other types of events. So let's say that this is the PushWebhookController. And this is going to start us out with several methods for the different types of HTTP requests. We have a couple of get methods, we have a post method, put and delete. Now, GitHub is going to make a post request to our webhook. So really, we can get rid of all of the other methods, and just have our post. And you can see that it is going to take the request body, and it's going to bind it to this value parameter. Now, that's not really going to help us in our case, because GitHub is going to send us a JSON payload. We want to parse that JSON into something that we can use programatically. Now MVC 6 can automatically do that for us. It's going to use json.net in order to parse it into something, so we can come in here and we can say this is going to be dynamic, and let's just call this payload. And then we could access all of the data programatically. And this is a viable option, we could do this. However, we would end up with a cleaner code if we just write a couple of classes to represent the things that we need from the JSON payload. All right, for example, let's open up that payload and if we look at the properties here, we need commits because that is going to contain the information that we need and really that's it. We might need a couple of other things later on. But, to start out with all we need are the commits. So we can have a class that is going to represent the payload as a whole. It will have a commits property. And then we could write another class that will have properties for the added, removed and modified arrays. So, two very simple classes, in order to give us easy access to the data that we need. Let's go to our models folder. Let's create a new folder called GitHub, and let's also be specific here, because we are getting a push event payload. So let's just call it PushPayload, because later on we might add another webhook for some other type of event, and it would have a different or slightly different payload. So it makes sense to call our classes what they actually represent. So we have our PushPayLoad, let's have our commits property which just needs to be an enumerable so we'll have an IList, we'll say that it will be commit, that's what we will call that class. And then for the name of this property, would be simply Commits. Now as I mentioned, MVC 6 is going to use json.net in order to parse the json into our PushPayLoad object. So we could come in here and use the json.net attributes. We can say JsonProperty and then commit. Now we actually don't have to do that here because json.net is going to be smart enough to recognize that the commits in the json Is going to map to this commits property. So we could do this if you wanted to be absolutely specific, but I'm going to omit that just to make things a little bit easier. Now we need our commit class, so we could add this in another file, but I'm just going to do that here. We'll call it Commit, and we need three things. We need three enumerable properties for the added, removed and modified. So, we will start with, let's start with added. This will be an IList of string, because that is all that we get within our payload. We have a string of the path of the file that was modified, removed, or added. So we will have an IList of string and this will be for the added files. We can copy and paste. We need one for the modified and then one for the removed, and once again we can come in here and use the json property attributes, but we don't need to. Now, it would also be helpful to have the time stamp. So let's go ahead and add that property as well. And this will be a date time. We'll go ahead and let json.net convert that time stamp Into something that we can programatically use. And we will call it Timestamp, and if we run across something else that we need, we can just easily add it. These are some very simple classes, there's nothing complex about it. So we can add things or take things away if we find that we don't need them. So let's come back to our controller. Instead of dynamic here, we want to use our PushPayLoad. We do need a using statement for our Models.Github name space, and then that will give us easy access to the data that we need. Now, you might be thinking that this is not secure, and you are 100% correct. The URL for this webhook is going to be api/, and then the name of the controller, PushWebhook. Now, we can of course change that, but let's just run with that for now. Anybody can send a properly formatted request to that URL. So they would send a JSON payload that has a single commit. And it could have all of the files inside of the removed array. And then our application would say okay I'm going to remove all of those files from the application's file storage. And so as far as our application is concerned, we would have no blog posts or articles or whatever we are displaying on our website. And that is not desirable. That is a huge security flaw. Now you might think that's well who's going to know about that URL, because we set that up through the settings of our repository. Only the people that have access to the repository settings can see that URL. And that's true, but obscurity is not security. But thankfully GitHub has a way of securing a webhook and we will look at that in the next lesson.