The purpose of this project is to create a self-host server with katana OWIN spec that is minimal for grant requestor access token and process refresh token without the database.
​
Visual Studio 2015 Community Version
Project Type: Windows Console Application with .NET Framework 4.5.2
Project Name: AWkatanaSelfhost
Package Install:
Microsoft.Owin.Host.Systemweb
In Package manager console:
PM> Install-Package Microsoft.Owin.Host.Systemweb
Install-Package Microsoft.AspNet.Identity.Core
Install-Package Microsoft.AspNet.Identity.Owin
Install-Package Microsoft.Owin.Security
Install-Package Microsoft.Owin.Hosting
Install-Package Microsoft.AspNet.WebApi.Owin
Install-Package Microsoft.Owin.Host.HttpListener
 

1. Create a new project, Select Console Applicaton with .NET framework 4.5.2

3. Open Program.cs file, and we will build a self-host web server in here. By using Microsoft.Owin.Hosting, you can add WebApp object in it and instruct the host to start the application from Startup class, which we will be building in the next step.
        static void Main(string[] args)
        {
            string baseUri = "http://localhost:8000";
 
            Console.WriteLine("Starting web Server...");
            WebApp.Start<Startup>(baseUri);
            Console.WriteLine("Server running at {0} - press Enter to quit. ", baseUri);
            Console.ReadLine();
        }
​

​4. Create a class called “Startup.cs” and inside of this file, add two references: System.Web.Http and Microsoft.Owin.  This is the place where we are building the OWIN with Katana component architecture. Using Microsoft’s OWIN IAppBuilder at the first method called configuration, we can build the OWIN HTTP pipelines.  There are just 3 separate tasks to build it. One is to configure the IAppBuilder app by supplying it with information like the token path and provider and custom options for Authentication pipeline since we are going to build our own token and refresh token. Second is to map the route of our resource. The third task will be bring the route information from the HttpConfiguration into the last pipeline.
​
        public void Configuration(IAppBuilder app)
        {
            ConfigureAuth(app);
            var webApiConfiguration = ConfigureWebApi();
            app.UseWebApi(webApiConfiguration);
        }
 
5. Create MyOAuthServerProvider class in the oAuthProviders folder.  This class is the brain of the entire architecture, where it validates the incoming credential against the security data we have on the server.  First, it analyzes the incoming data and determines if this is a new requestor for the access token or a return requestor who requests the renewal access token by using the refresh token. The ValidateClientAuthentication method will decipher the incoming data and determine the next action.  If it receives user and password and the grant type is password, it will pass to GrantResourceOwnerCredential method for further verification and will determine to grant an access token or reject to the requestor. If it receives refresh token and the grant type is refresh_token, then the GrantRefreshToken method will receive the call from the ValidateClientAuthentication method, and then it will issue a brand new ticket containing the new access token when it is validated. 

6. Create MyRefreshTokenProvider class.  This class is self-explanatory where we implement the IAuthenticationTokenProvider interface from the OWIN.Security.  Here we can customize our refresh token.  In our project, we just create it as GUID data type. 

7. Create a simple API called FruitController as our resource where the requestor can access our secret Fruit List after their credential has been verified and use the obtained token to access the API.  There is no need to pass the username and password again when accessing the protected resource.  The API can be protected by simply using the [Authorize] attribute in front the controller or individual method.
​
The Self-Host project is now completed with 7 simple steps.

Many articles and code samples explaining the OWIN usually stop at how to generate the access token and did not reveal the mechanism of how the refresh token work in codes.  The trick is not in the MyRefreshTokenProvider, but rather, it’s in the MyOAuthServerProvider class.  The OWIN’s specification said the only required parameters are “grant_type” and “refresh_token” like showing below:

   grant_type: refresh_token
   refresh_token: 3a3aebea-4150-4850-8e37-ace1d9eead9a [this is our sample and you may have other format]

There are many ways to accomplish the same thing, but in our project, the trick is to have another authentication property called “as:client_id” hidden in the original ticket when the requestor requested for the first time.  When the return requestor comes again with the refresh token and asks for a new access token, the ValidateClientAuthentication method can verify the clientId and clientSecret against the original ticket so that we are sure that this requestor is the original requestor.   Without this trick, the GrantRefreshToken method will never receive the call even the grant_type and refresh_token parameters have been passed in. A generic error message, such as “invalid_grant” can be resulted, and you may not know why.

This Client app will be the requestor for the AW Kantana Self-Host.
Create another .NET console project in another Solution, and we are going to build the Client that requests the access token to access the protected resources.
​
Project Type: Windows Console Application with .NET Framework 4.5.2
Project Name: AWkatanaClient
Package Install:
PM> Install-Package Microsoft.AspNet.WebApi.Client

I’ve created two separate methods in the Main(). One is to demonstrate how refresh token works, and another method demonstrates how to access protected resource.  You can comment out one of them to examine the mechanism of token generation and consumption.  Please run the AWKatanaHost project first and then AWkatanaClient later in order to have a correct testing experience. See the results below:

Postman is a tool that you can install or add to Chrome as an add-in.  Basically, Postman acts as a client that passes an HTTP POST with your desired parameters in the header and body to the host.  Before you use the tool, you need to have a solid understanding of how client-server communicates.  The communication is made possible because of HTTP protocol contains rules and information in their request/response body which dictates how client like the browser to behave and how the server should handle.  To test our AWkatanaSelfhost project, we need to use “POST” instead of the “GET” action. Download Postman

​1. Change to “POST” from the drop down list
2. On the url text box: http://localhost:8000/Token
3. Click on “Body” tab, and ignore “Authorization” and “Headers” tabs
3. Select radio button: application/x-www-form-urlencoded
4. Add the following keys and values
grant_type: password
username: arthur@startrek.com
password: enterprise
client_id: 12345
client_secret: secret
5. Click on the “Send” button

​1. Copy the access_token value from previous response body [yes, the whole thing; 3 lines]
2. Create another tab and change to “POST”
3. On the url text box: http://localhost:8000/api/Fruits
4. Click on “Headers” tab, and put this key and value [Remember: in headers and NOT in body]
Authorization: Bearer AQAAANCMnd8BFdERjHoAwE_Cl-A..<---your access token code here
5. Click on the “Send” button

​1. Copy the refresh_token value from the first response body [e.g. 870dd360-f41e-48e9-91d7-2790b0dc11aa]
2. Create another tab and change to “POST”
3. On the url text box: http://localhost:8000/Token
4. Click on “Body” tab, and put this key and value
grant_type: refresh_token
refresh_token: 870dd360-f41e-48e9-91d7-2790b0dc11aafrom step #1
client_id: 12345
client_secret: secret
5. Click on the “Send” button

I hope this article is fun and helpful for you to learn to use OAuth 2.0 to secure your API services by using Katana.  You can download the codes from here:

• AWkatanaSelfhost
• AWkatanaClient

​Useful Links
Postman Tool - https://www.getpostman.com
OAuth 2.0 Official Standards- https://tools.ietf.org/html/rfc6749#section-4.3.2

​If you are new to Visual Studio 2015 and wonder why all these external web development tools, such as Bower, NPM, or Grunt, were included in the new Visual Studio, then this article is for you.  There are tons of articles written on how to use specific tools and recommendations on which one is better than others.  In this article, we want to try to describe the ecosystem of these modern web development tools in a big picture and how tools have become complicated over time.  The quick and straightforward examples shown here will help you to get started with these tools and understand the reason behinds.

As the ASP.NET developers, we are used to having .NET Framework version upgrades and additional features like NuGet Package Manager and more whenever a new version of Visual Studio comes out.  But this time is not like that. The familiar folder structure is gone, and the web.config file is gone. The folder structure is quite different. There is even a ghostly “Dependencies” folder which appears in the Visual Studio Solution Explorer but not in the physical folders and there are unfamiliar default files [See figure below]. People even seem to move away from using Web Essentials, the Visual Studio Extension, which was a way to use the external tools outside of Visual Studio.  And even the use of NuGet Package Manager is discouraging, and instead, we are seeing more command line tools flourishing in the web development landscape as it seems like we were going backward to early DOS age after all these years of advances.  Are we going back to square one and what’s going on?

As the Visual Studio users, we are used to let NuGet manage our dependencies, and there is no doubt that it was a great tool.  However, NuGet is gearing toward for the Microsoft .NET ecosystem, and not all client-side libraries are submitted to the NuGet repository.  The Visual Studio users may cut from the outside world and unable to obtain the latest packages or new technologies.  As a result, Visual Studio needs to align itself to adopt the thriving development community. They do not have the resource to chase the trend and reinvent the wheels.  With the time constraint, Visual Studio still finds ways to integrate these new tools into the web development.
 
There are two popular package managers, Bower and NPM, tend to replace the NuGet tool, at least for the non-.NET component such as JavaScript or CSS.  You just need to choose one or both to manage your dependencies. NPM can be used for both server-side node packages and client-side packages.  Bower is more popular client side package manager..

If you use Visual Studio 2015, NPM, Bower will be installed by default.  And you can manage these tool versions from Tool --> Options --> Project and Solutions --> External Web Tools  

​This list shown on the right from the Option window tells Visual Studio where to find dependencies starting from top to bottom. So the Visual Studio program looks for node_modules\bin folder from your project first, and if it cannot find it, it will look for the folder under C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External and so forth.

​If you do not use Visual Studio, then you need to install them yourselves in this order.
1. Install node.js from nodejs.org, and it will also install npm by default
2. Install with a command line to install bower by using npm [npm install bower –g]
3. Install Git by using http://msysgit.github.io/  and use Git to download packages from GitHub.  

​For Windows users, we are so used to have no-brainer installation in the Windows environment.  Just double click and install. But to install a web development tool without Visual Studio 2015, there are so many steps just to install these tools, and we have not even talked about how to use them yet.  Life is easier in Visual Studio 2015.  Before we talked about how to use them in VS 2015, let’s compare Bower and NPM since they are doing the similar things like package managers, but it really dependent on your needs.  For example, if you need to keep two versions of jQuery in the production, then you need to use NPM, but if you need only one single copy of jQuery, you should use Bower since it just installs the designated version packages that you specified. So initially NPM is used for installing Node.js modules, and Bower.js is leaning toward on the use of managing the front end components like CSS, JS, etc. 

Here is how npm works:
 
There is a registry on the internet (npmjs.org) where tool developers can publish their works, and it is powered by the CouchDB database.  Once you installed the node.js on your local machine, from a command line, you can invoke npm.exe to manage your packages.  In your project folder, you will need a meta file named package.json that instructs npm on what to do.  The npm will go to the npm registry to find your missing packages and bring them into node_modules folder on your local machine. 

​So in Visual Studio 2015, all you need to do is to open the package.json file, and add the name of the package and its version under the devDependencies section, and as soon as you hit the save button, Visual Studio will act as a proxy to npm to grab those packages for you. 

​As you may have notice that each package manager has its own destination folder for the packages that it stores. Bower stores in the bower_components folder and NPM stores in the node_modules folder. In this case, we need to have another build step to copy those packages into our web development or production folder from the package folder.  For example, if we use AngularJS in the development, our AngularJS files may be located in node_modules folder if we use NPM, and we want packages to be located in our wwwroot/js folder.  Grunt and Gulp are the two of the most popular build systems out there to do these tasks. However, NPM can act as a build tool as well if you use its createReadStream function.  Nevertheless, if you need more complex build process, many people will likely choose either Grunt or Gulp since it has a lot of plugins to choose from.  In Visual Studio, these tasks located inside the Grunt or Gulp script can be managed via Task Runner Explorer.  You can do more inside the Task Runner Explorer when you right click on the task.

Conclusion
 
In this article, we have seen how these little tools such as the npm, grunt, and many others, are quite powerful, and they can do a lot of things for us as developers.  The tools help us from managing our dependencies to our build process, and they could also help us test and do continuous integration if we spend some time to configure them with scripts and a workable deployment pipeline can be built at the end. However, because of these tools live in an open source environment, there is no one to supervise and manage, it has its advantages, and there are some disadvantages as well.  When you need a tool's plugin to do something, you may find that you need more dependencies after dependencies, and sometimes it may add unwanted file size to your project.  There are more tools to fill the gaps of other tools. There are management tools to manage other management tools.  There are fixes and upgrades within the tools, configuration scripts may work for a few months and may not work if you upgrade certain tools.  It is an age of disruptor overboard, and it is quite a chaos if you think about it.  Regardless of the frustration that some developers may have experienced, we need to do our part of finding the right tools by testing and prototyping the workflows that fit our needs.  We should always have backup copies of these tools stored somewhere you can access since the process often assumes that you have an internet access.  On the security issue, we should also be alert to the risk of having such an easy but powerful tool like the npm.  Since node.js was already installed on our side, and this is always a vulnerability of allowing the malicious package to come in without any supervision.  Hopefully, the technology will become more mature and reliable sooner. ​The developers can spend more time on building great software and spend less time on finding the right tools for the right jobs and then figuring out how to use the tools to their best interests.  Perhaps, Visual Studio can tame the modern web development tools in the future version.

The EASY way is to have .NET 4 Framework or above and reference System.Device.dll, and using namespace found in System.Device.Location. (You should see it if you are developing a Windows Phone program) There is a method called GetDistanceTo().

Here is a quick example:

var location1 = new GeoCoordinates(-29.83245, 31.04034);
var location2 = new GeoCoordinates(-51.39792, -0.12084);
double distance = location1 .GetDistanceTo(location2);

Please note that the method returns in km (kilometer).

Under the hood
The formulas used in the method is actually using the Haversine method. It assumes that the earth is a perfect sphere rather than an ellipsoid, so as a result, it has an error of less than 0.1 percent.  
Since it didn't account for altitude in its calculation, the distance is shorter than the driving distance.

Here is the LONG way:

    public class GeoCoordinate
    {
        public double Latitude { get; set; }
        public double Longitude { get; set; }
    }

    public class GeoCoordinateTool
    {
        public double Distance(GeoCoordinate loc1, GeoCoordinate loc2, int type)
        {
            //1- miles, other km
            //Use 3960 if you want miles; use 6371 if you want km
            double R = (type == 1) ? 3960 : 6371;          // R is earth radius.
            double dLat = this.toRadian(loc2.Latitude - loc1.Latitude);
            double dLon = this.toRadian(loc2.Longitude - loc1.Longitude);

            double a = Math.Sin(dLat / 2) * Math.Sin(dLat / 2) + Math.Cos(this.toRadian(loc1.Latitude)) * Math.Cos(this.toRadian(loc2.Latitude)) * Math.Sin(dLon / 2) * Math.Sin(dLon / 2);

            double c = 2 * Math.Asin(Math.Min(1, Math.Sqrt(a)));
            double d = R * c;

            return d;
        }

        private double toRadian(double val)
        {
            return (Math.PI / 180) * val;
        }
    }

How to use this class?

            GeoCoordinate g1 = new GeoCoordinate();
            GeoCoordinate g2 = new GeoCoordinate();

            g1.Latitude =-29.83245;
            g1.Longitude = 31.04034;

            g2.Latitude = -51.39792;
            g2.Longitude = -0.12084;

      var geotool = new GeoCoordinateTool();
      var distance = geotool.Distance(g1, g2, 1);

search texts: easiest way to calculate a distance, example of using GetDistanceTo, without Google Maps API