Richard Banks

Improving performance with .NET Core 3.0

Fri, 02 Aug 2019 01:15:00 +0000

The week I gave a talk at the Sydney Alt.Net Meetup about using .NET Core 3.0, Span, stackalloc, and other newer .NET features to improve performance of an application.

In it I showed a specific scenario where I used a PDF library (PdfPig) to count the words in a PDF file, and in less than an hour improved the performance by over 30%.

Much of the talk centered around actually making the performance improvements and shortly I’ll create a video showing that side of the talk, and how PerfView and benchmarkDotNet can be used to help.

For now, you can look at the code at various stages of improvement by jumping between the different branches of my cloned PdfPig repo at https://github.com/rbanks54/PdfPig.

Here are the branches you might want to look at:

master: the code “as-is”, simply the snapshot of the original library, with no changes.
startPoint: Converted to .NET Core 3.0 and with a “performanceTester” utility you can run to see overall performance for our test scenario. You can switch the csproj to netcoreapp2.2 to see the difference between Core 3.0 and Core 2.2
numericTokens: Added microbenchmarking and improved performance of the numeric token parser. Run the benchmarks program to see the numbers
NameTokens: microbenchmarking, with multiple approaches. Use the benchmarks to compare performance differences of various approaches. Run with “-m” to see the memory usage stats.
both-tokens: code with both the numeric and name token improvements in it. Run the performanceTester to compare with the original code.

Code splitting in Vue

Sun, 20 Jan 2019 21:30:00 +0000

I have a small personal project I’m building with Vue and Webpack v4. I noticed that the production bundle size was starting to get a bit large (3.4 Mb).

A bundle of this size will be slow to load and people on slow connections might think the web app is failing to load and leave the site.

Time to do some code splitting.

If you’ve not heard of the term before, code splitting aims to reduce the size of the JavaScript loaded for a site to just the code needed to serve up the initial view. Any JavaScript needed after that is loaded asynchronously, and on demand.

With Vue this is really quite easy!

How easy, you ask? Let’s have a look.

Route splitting

Since we want the initial bundle to only contain code need for loading the site, we don’t need any of code used elsewhere in our app. Splitting out components loaded only when people navigate elsewhere is perfect for this.

To given you an example, here’s the extent of my changes needed to split out an admin component into a separate bundle:

// Original code
import AdminContainer from 'pages/AdminContainer'

// Changed to
const AdminContainer = () => import(/* webpackChunkName: "admin-container" */ 'pages/AdminContainer');

And that comment for the webpackChunkName? It’s not even required! That’s just so I can name the bundle the way I want.

And that’s it! A one line change and we’re all done. Wow!

OK, Not quite

Yes. I lie a little. I also had to add this single to my .babelrc file to handle the dynamic import statement:

  "plugins": ["@babel/plugin-syntax-dynamic-import"]

Pretty cool, right?

It’s not just for Vue components

I use PdfMake to create PDF files in the browser, and have put all the code related to generating PDFs in a module I named pdfGenerator (I know, so creative!).

Instead of having all the PDF generation code in my initial bundle, I can split it out into it’s own bundle and only load it on demand.

We can still use the dynamic import statement, but we have to keep in mind that the dynamic import returns a promise, and when the promise resolves our callback will be passed the module that was loaded.

So, my code for generating a PDF now becomes something like this

const pdfGenerator = () => import('@/services/pdfGenerator');

export default {
  //.. rest of Vue component
  methods: {
    pdfGenerator().then(module => {
        var generate = module.default; //the default export from the imported module
        generate(this.someValue, this.someOtherValue);
    }
  }
};

It’s a little more code, but still really easy to use dynamic imports and the approach means we can separately load JavaScript needed on a function specific basis, not just when Vue components are loaded.

Conclusion

By using just some basic route-based splitting and delaying the loading of the PDF functionality until it’s needed, I turned what was a 3.4 Mb bundle into a 1.2 Mb bundle in about 20 minutes of work, including testing time.

I’m pretty happy with that, and there’s still more I can do to further optimise the initial bundle size and make the load time of my web app even quicker.

Securing a Vue.js app and API with IdentityServer - Part 9

Mon, 12 Nov 2018 03:00:00 +0000

This is part 9 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer
Part 3 - Adding Google Authentication to IdentityServer
Part 4 - Creating and securing an ASP.NET Core Web API
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js
Part 7 - Securing a router view in Vue.js
Part 8 - Calling a secured API from Vue.js
Part 9 - Refreshing identity tokens with Vue.js (this post)

Refresh tokens

You’ll find that if you leave the Vue app running for long enough that eventually the identity token will expire and you’ll need to sign in again.

If this happens too regularly users will complain of a poor user experience and get a bit annoyed with your application. Let’s have a look at how we can configure our application to automatically refresh the identity token once it gets close to expiring.

Ideally, we don’t want our users to know that the token has been refreshed. We want token renewal to occur without interrupting the user experience or breaking the behaviour of the application in any way.

The oidc-client provides this functionality for us via its automatic silent renewal feature.

Let’s add this to our code by adjusting the configuration of the UserManager in services/security.js.

Add the following properties where we create the UserManager object

    automaticSilentRenew: true,
    silent_redirect_uri: 'https://localhost:5000/static/silent-renew.html',
    accessTokenExpiringNotificationTime: 10,

You’ll note that silent-renew.html is a static page, not a Vue component. This is to avoid the overhead of creating a new Vue instance, and to limit any risk of interrupting work happening in the main application. The silent-renew.html page is simply a callback to complete the token renewal process and we’re only using it to update our token stored in the browser’s local storage. We don’t need to update and any of Vue’s state information.

Now, because we’re changing the client to support silent renewal, we need to adjust the client registration in IdentityServer as well.

We’re going to shorten our token lifetime to 90 seconds to avoid waiting 2 hours for tokens to expire, and we’ll also add a new RedirectUri, enable AllowOfflineAccess and disable the RequireConsent flag. For this post we’ll also be using a sliding expiration approach so that as long as the tokens keep getting regularly refreshed, you’ll remain logged in.

Here’s the extra client configuration code you need in Config.cs of your IdentityServer project

  AllowOfflineAccess = true,
  AccessTokenLifetime = 90, // 1.5 minutes
  AbsoluteRefreshTokenLifetime = 0,
  RefreshTokenUsage = TokenUsage.OneTimeOnly,
  RefreshTokenExpiration = TokenExpiration.Sliding,
  UpdateAccessTokenClaimsOnRefresh = true,
  RequireConsent = false,

  RedirectUris = {
      "https://localhost:5000/callback",
      "https://localhost:5000/static/silent-renew.html"
  },

Back in our vue-app, we now need to implement the silent-renew callback page. We’ll need to include the oidc-client and a simple call to trigger the callback completion method.

Create a static folder in /public, and then create a /public/static/silent-renew.html page with the following content.

<!DOCTYPE html>
<html>
<head>
    <title>Silent Renew Token</title>
</head>
<body>
    <script src='oidc-client.min.js'></script>
    <script>      
        console.log('renewing tokens');
        new Oidc.UserManager({userStore: new Oidc.WebStorageStateStore({ store: window.localStorage })})
            .signinSilentCallback();
    </script>
</body>
</html>

Since this is static content and we’re not building anything with Webpack, we need to copy oidc-client.min.js from vue-app\node_modules\oidc-client\dist\oidc-client.min.js into the /public/static folder.

If you haven’t already done so, build and restart both your identity server and your vue-app sites.

Browse to the /about page and ensure you can still make the secure API call.

Now you’ll just have to wait 90 seconds to see if your token refreshes. You should be able to see network activity using your browser’s developer tools, and you should see the "renewing tokens" message in the console.

Conclusion

That’s it! We’re done!

I hope you’ve found this series useful and that it helps you in your development efforts!

If you have any feedback, reach out and let me know. Also, if you notice any bugs or issues with the code, head over to GitHub project and let me know there.

Securing a Vue.js app and API with IdentityServer - Part 8

Mon, 12 Nov 2018 02:30:00 +0000

This is part 8 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer
Part 3 - Adding Google Authentication to IdentityServer
Part 4 - Creating and securing an ASP.NET Core Web API
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js
Part 7 - Securing a router view in Vue.js
Part 8 - Calling a secured API from Vue.js (this post)
Part 9 - Refreshing identity tokens with Vue.js

Calling a secured API from Vue.js

Hopefully you’ve been following along with the previous posts. You should now have a working Vue.js app, be prompted to log in via IdentityServer when browsing to the /about page, and can show data returned from an unsecured API on that page.

Let’s extend the /about page to show data from our secured /api/services API.

Adjust the about.vue <template> as follows:

    <button @click="callApi">Call API</button>
    <button @click="callSecureApi">Call Secure API</button>
    <div v-for="(service,index) in services" :key="index">
      <p>
        <img src="service.iconUri" />
        <a href="service.uri"></a>
      </p>
    </div>
  </div>

Add a services property to the component’s data in the <script> section

  data() {
    return {
      values: ["no data yet"],
      services: []
    }
  },

And then add a new method for calling the API and populating data with the result

    async callSecureApi() {
      try {
        const response = await axios.get("https://localhost:5000/api/services");
        this.services = response.data;
      } catch (err) {
        console.log('secure api call failed');
      }
    }

Because this is a secured API, we need to provide an identity token in the request headers when making the call. If we had to write code to do this every time we made a API call it would be a painful experience, and no one wants that!

This is where Axios becomes very handy! Axios supports the concept of interceptors. Methods that run before or after network calls. We’ll add an interceptor before each network call, so that any time we have a valid security token we’ll automatically attach it to the request headers.

Head over to main.js one more time and import the axios module

import axios from 'axios'

Now add a request interceptor for Axios to the end of the file.

axios.interceptors.request.use((config) => {
  const user = v.$root.user;
  if (user) {
    const authToken = user.access_token;
    if (authToken) {
      config.headers.Authorization = `Bearer ${authToken}`;
    }
  }
  return config;
},
(err) => {
  //What do you want to do when a call fails?
});

You’ll see that we’re using a variable 'v' that we haven’t defined yet.

This will be the root Vue instance, which we need if we want to access the UserManager information. Adjust the Vue declaration as follows

let v = new Vue({
  router,
//…

Now let’s cross our fingers, take a deep breath, and give it a try!

Browse to the site (https://localhost:5000), navigate to the /about page, sign in (if prompted), and then click the button to call the secure API.

Hopefully, you haven’t missed anything along the way and it all works for you. Raise your fists in the air in victory and give yourself a pay raise!

A few things to note: Because we haven’t implemented any logout functionality if you ever want to reset and sign in from scratch, you’ll need to browse to IdentityServer and click the logout button (it’s under your user name),and you’ll have to clear your browser local storage to remove any tokens stored there. Alternatively, just start an incognito/inPrivate browser session and use that.

If you want to implement the sign out process yourself, you’ll need to call the singoutRedirect() method from oidc-client, but we won’t be doing that in this series.

We’re pretty much done, but there’s one last thing we should look at. How do we refresh our identity tokens so we’re not signed out so regularly?

Up Next: Part 9 - Refreshing identity tokens with Vue.js

Securing a Vue.js app and API with IdentityServer - Part 7

Mon, 12 Nov 2018 02:00:00 +0000

This is part 7 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer
Part 3 - Adding Google Authentication to IdentityServer
Part 4 - Creating and securing an ASP.NET Core Web API
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js
Part 7 - Securing a router view in Vue.js (this post)
Part 8 - Calling a secured API from Vue.js
Part 9 - Refreshing identity tokens with Vue.js

Securing a route in Vue.js

Just to recap on what we’ve done so far… we have an IdentityServer instance up and running, we have a site serving up an ASP.NET Core Web API and the built JavaScript files from our Vue.js SPA, and we’ve been able to retrieve data from our back end API and show it on the browser. Have a look at the prior parts in this series if you need to catch up.

We now want to secure access to the About page so that people are automatically signed in when they browse the about page. This will also mean we have the necessary security tokens available when we make the call to the secured API (in the next post).

When it comes to routing, the Vue Router is the library of choice for Vue. With vue-router we are able to write navigation guards to protect access to URIs. When someone tries to access a secured page, we’re going to see if they have any credentials and if they don’t we’re going to prompt for them (i.e. redirect them to sign in).

We begin by marking the /about route as secured by adding extra metadata fields to it. Edit the router.js file and add the meta properties as shown

    {
      path: '/about',
      name: 'about',
      meta: {
        requiresAuth: true
      },

We now need to adjust the export statement. We’ll store the router instance in a variable, and export that variable rather than the object itself. This is so we can perform some other actions with the router instance later in the file.

Change this code:

export default new Router({
  //...
})

To the following:

let router = new Router({
  //…
})

export default router;

Next up; let’s implement the navigation guard. Add this code to the router.js file

router.beforeEach(async (to, from, next) => {
  let app = router.app.$data || {isAuthenticated: false} ;
  if (app.isAuthenticated) {
    //already signed in, we can navigate anywhere
    next()
  } else if (to.matched.some(record => record.meta.requiresAuth)) {
    //authentication is required. Trigger the sign in process, including the return URI
    router.app.authenticate(to.path).then(() => {
      console.log('authenticating a protected url:' + to.path);
      next();
    });
  } else {
    //No auth required. We can navigate
    next()
  }
});

The router.app variable references the base Vue instance (see the docs), but it won’t be populated the very first time the router is called. For this reason we provide a default value.

If this was a more “real-world” application we’d probably be using Vuex or Redux to store authentication data, and we wouldn’t need to access the router.app value like we’re doing here. Doing that in this series would make it even bigger than it already is, and it’s long enough already so we’ll keep it simplistic for now, work around this little problem, and get on with it. Have a look at how you can manage application state using Vuex once you’ve finished here.

Those changes made, head over to main.js and change the contents to look as follows:

const globalData = {
  isAuthenticated: false
}

const globalMethods = {
  async authenticate(returnPath) {
    console.log('yet to be implemented');
  }
}

new Vue({
  router,
  data: globalData,
  methods: globalMethods,
  render: h => h(App),
}).$mount('#app')

We’re simply declaring some fields and methods and attaching them to the root Vue instance (because we’re not using Vuex) so we can access them in the router navigation guards.

If you now browse to the site and navigate to the /about page you should see in the browser console a few messages indicating our authenticate() method is being called

Signing in with OpenId Connect

Great! Let’s get back to implementing our OpenId Connect sign in process.

We begin by including a JavaScript library that helps with the low-level security handshake and plumbing work. This is the oidc-client library, written by the IdentityServer team and hosted on GitHub.

Add this to our vue-app by going to the command line and running

yarn add oidc-client

Now let’s add a new folder called security to our /vue-app/src folder, and create a security.js file in that folder. This will be where we put our code to handle much of the security and OpenId Connect calls.

The oidc-client library provides a UserManager object that we can configure for communicating with IdentityServer. The configuration details we supply here must match the client information we created in IdentityServer, otherwise IdentityServer will reject the connection.

Let’s get this sorted out by adding the following code:

import Oidc from 'oidc-client';

var mgr = new Oidc.UserManager({
    authority: 'https://localhost:5443',
    client_id: 'js',
    redirect_uri: 'https://localhost:5000/callback',
    response_type: 'id_token token',
    scope: 'openid profile api1',
    post_logout_redirect_uri: 'https://localhost:5000/',
    userStore: new Oidc.WebStorageStateStore({ store: window.localStorage }),
})

You’ll note that we’re configuring the userStore field to use browser local storage. This will prevent information loss when the web app is reloaded.

If you’re the curious sort and would like to see logging information from within the library simply add the following lines below the UserManager declaration. It’s entirely option, and if you do use it, remember to disable it in production, okay?

Oidc.Log.logger = console;
Oidc.Log.level = Oidc.Log.INFO;

We also need to export the UserManager instance from our module, so add the following to the end of the security.js file

export default mgr;

Now, let’s head back to the vue-app/src/main.js file and flesh out the authenticate() method.

We want to check if a user is already known and if not, we want to trigger the sign in process. We’re going to pass along the path we were trying to reach with our sign in request so that when the callback completes we can resume navigation to the target page.

Here’s an implementation you can use:

Firstly, let’s import our user manager from our security module. Add the following line to the top of your file, where the other import statements are.

import mgr from './services/security.js'

And then include it in our global data, and implement the authenticate method.

const globalData = {
  isAuthenticated: false,
  user: '',
  mgr: mgr
}

const globalMethods = {
  async authenticate(returnPath) {
    const user = await this.$root.getUser(); //see if the user details are in local storage
    if (!!user) {
      this.isAuthenticated = true;
      this.user = user;
    } else {
      await this.$root.signIn(returnPath);
    }
  },
  async getUser () {
    try {
      let user = await this.mgr.getUser();
      return user;
    } catch (err) {
      console.log(err);
    }
  },
  signIn (returnPath) {
    returnPath ? this.mgr.signinRedirect({ state: returnPath })
        : this.mgr.signinRedirect();
  }
}

If your’re not that familiar with vue, this.$root will return the root vue instance, which is where our methods and data fields are defined.

We’re still not quite done, but it’s always a good idea to see if things are working before getting too far ahead of ourselves.

Make sure everything builds correctly, and then browse to the home page (https://localhost:5000).

If you navigate to the /about page, you should get redirected to the identity server sign in page.Once you sign in (try: alice/password) then you’ll be prompted with the permission page.

If you choose to continue, and you should, you’ll be redirected to the callback page. It won’t work as we haven’t yet implemented it yet, but we’ve proven the previous steps are working.

Se let’s add a new vue page to /src/views called Callback.vue.

Add the following code to it.

<template>
    <div>
        <p>Sign-in in progress</p>
    </div>
</template>

<script>
    export default {
        async created() {
            try {
                var result = await this.$root.mgr.signinRedirectCallback();
                var returnToUrl = '/';
                if (result.state !== undefined) { returnToUrl = result.state;}
                this.$router.push({ path: returnToUrl });
            } catch (e) {
                this.$router.push({ name: 'Unauthorized' });
            }
        }
    }
</script>

This callback simply completes the sign in process using the oidc-client library and then redirects to either the home page or the target URL (if we supplied one).

We’ll also need to add this component to our routing table.

import Callback from './views/Callback'
//…
let router = new Router({
	//…
    {
      path: '/callback',
      name: 'callback',
      component: Callback
    },
	//..

There’s just one last thing we should do. Now that we can log in, let’s call that secured API and complete the loop!

Up Next: Part 8 - Calling a secured API from Vue.js

Securing a Vue.js app and API with IdentityServer - Part 6

Mon, 12 Nov 2018 01:30:00 +0000

This is part 6 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer
Part 3 - Adding Google Authentication to IdentityServer
Part 4 - Creating and securing an ASP.NET Core Web API
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js (this post)
Part 7 - Securing a router view in Vue.js
Part 8 - Calling a secured API from Vue.js
Part 9 - Refreshing identity tokens with Vue.js

Calling An API from Vue.js

Before we call our secured API, let’s just make sure we can call our unsecured /api/values API first.

The default vue app we generated has a simple About page, so we’ll just repurpose that page instead of adding any new routes to our app.

To make our API calls we’re going to use the Axios library.

From your command line, ensure you’re in the vue-app folder (i.e. where your JS client source is) and then run

yarn add axios

Next up, let’s edit the src/views/About.vue component to display the values return from the /api/values endpoint.

Change the template to be:

<template>
  <div class="about">
    <h1>This is an about page</h1>
    <div v-for="(item,index) in values" :key="index">
      <p></p>
    </div>
    <button @click="callApi">Call API</button>
  </div>
</template>

And then add a script section to the component (in the same file) for responding to the button click event

<script>
import axios from 'axios'

export default {
  data() {
    return {
      values: ["no data yet"],
    }
  },
  methods: {
    async callApi() {
      try {
        const response = await axios.get("https://localhost:5000/api/values");
        this.values = response.data;
      } catch (err) {
        this.values.push("Ooops!" + err);
      }
    }
  }
}
</script>

Save the file. If you enabled the watch option in your build task you should now be able to switch to the browser and refresh the page.

Rebuild the app (see part 5) and navigate to the About page, click the Call API button. you should see the following:

Sure, it’s not the most exciting thing in the world but we’ve proven that we can call our backend correctly and that everything works as expected. When doing software development it’s always good to build something small and then iterate on it until it’s complete.

Up Next: Part 7 - Securing a router view in Vue.js

Securing a Vue.js app and API with IdentityServer - Part 5

Mon, 12 Nov 2018 01:00:00 +0000

This is part 5 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Creating a Vue.js Client app

For this part of the exercise, we’re going to need a few tools to be installed.

We’ll need yarn installed (or you can use npm if you prefer), and we’ll also need to add the vue-cli utility.

Assuming you’re using Windows you can either manually install it, or use Chocolatey. Either way, the instructions are at https://yarnpkg.com/en/docs/install, and I’ll leave it as an exercise for you to complete. (P.S. My personal preference is to install using Chocolatey)

Once Yarn is ready you can install the Vue CLI using

yarn global add @vue/cli

This will add the vue command to your path and allow us to move on with the next step in our plans for world domination. Mwahahaha!! Oh… sorry. Got carried away there. Yes. Where, were we?

Create a basic vue application

Open a command prompt and set your current location to the root folder for your solution (e.g. c:\src) and run the following command:

vue create -n vue-app

The -n option tells the vue-cli to not initialise a git repository as this is an existing project and we (should) already have one.

When prompted, choose to manually select features. Include the router and exclude any linting options, then select the defaults for the prompts that follow by pressing enter. Note that the arrow keys will move between options and the spacebar will toggle the highlighted option.

This will create a default application in the src/vue-app folder.

When we build our Vue code, we’ll deploy it to the wwwroot folder of our VueApi site in order to serve it up to browsers.

Configure the vue-cli-service

Vue provides a service that supports the building and serving JavaScript applications. You can see more about what it does at https://cli.vuejs.org/

Since we’re going to be serving the JavaScript content from our existing web API site, we won’t need the cli-service’s web server capabilities. We’re only interested in the building and packaging of our vue files for distribution.

The defaults provided by vue are good for many people, but won’t quite work for us so we’ll need to configure things slightly.

If we wanted, we could configure everything via JavaScript config files, but since vue-cli provides a handy UI for managing the basics of these configurations, and I know how many people like using UIs, we’ll go down that path instead.

From your command line, set your current directory to the new vue-app folder and start the UI by running

vue ui

Go to the project manager (http://localhost:8000/project/select) and choose to import an existing project by clicking “Import this folder”

Once the project is loaded, the UI will show you the project dashboard. Select the configuration menu and adjust the setting for the Output Directory to use ../vueApi/wwwroot as follows:

Next, head to the tasks section are select the build task.

Click the parameters button and ensure that Modern Mode is off, the env mode is set to development, and set the output directory to ../vueApi/wwwroot (the same folder we used in the overall configuration).

You can also enable watch for changes so that whenever any of our vue-app source files are saved the vue-cli-service will automatically rebuild our code and copy it to our output folder.

Start the build task and look in the output tab to ensure some activity is occurring.

The dashboard should also be showing fresh data for you to look at

Serving up the SPA

This is a good start, but before we get too excited we want to ensure we can serve up our the build output to our visitors.

Head back over to Startup.cs in the Web API project and in the Configure() method replace app.UseMvc() with

            app.UseDefaultFiles();
            app.UseStaticFiles();
            app.UseMvc(routes =>
            {
                routes.MapSpaFallbackRoute(
                    name: "spa-fallback",
                    defaults: new { controller = "CatchAll", action = "Index" });
            });

The CatchAll controller will simply ensure that direct browsing to a non-root URL will still serve up the vue application. Routing in Vue will then determine which components get rendered.

Add an empty MVC controller named CatchAllController, and change the Index method as follows

        public IActionResult Index()
        {
            return File("~/index.html", "text/html");
        }

OK. Let’s give it a go.

Start the web app (the VueApi application) and browse to the root at https://localhost:5000. You should see the following:

Wonderful! We now have our JavaScript build environment up and running, and we’re able to serve up the static content to our site visitors.

Up Next: Part 6 - Calling an HTTP API from Vue.js

Securing a Vue.js app and API with IdentityServer - Part 4

Mon, 12 Nov 2018 00:30:00 +0000

This is part 4 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer
Part 3 - Adding Google Authentication to IdentityServer
Part 4 - Creating and securing an ASP.NET Core Web API (this post)
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js
Part 7 - Securing a router view in Vue.js
Part 8 - Calling a secured API from Vue.js
Part 9 - Refreshing identity tokens with Vue.js

Creating and Securing a Web API

If you’re joining the series now, then welcome! We’re assuming you have followed along with the previous parts in the series, so it may be worth familiarising yourself with them before continuing.

We’re going to go back to our VueAPI project now, and you may recall that the default project template we use gives us a simple ValuesController.

We’re going to leave that untouched as we’ll be using it to make sure unauthenticated access is still working as expected.

We’ll extend our API by adding a new controller that returns a list of objects. When we get to creating our Vue.js client application we’ll be showing these objects on the page, but only for authenticated users.

To create the API, right click the Controllers folder in Visual Studio and choose to add an empty API Controller named ServicesController.

We’re going to return a list of services my current employer Readify offers. I know you’d love you to explore and see how Readify can help you but for now I’ll ask you to pay attention to this blog series and visit the site later.

The API we’ll provide is going to return a collection of objects with service metadata. Here’s an implementation you can copy and paste if you’re following along.

[Route("api/[controller]")]
[ApiController]
public class ServicesController : ControllerBase
{
    [HttpGet]
    public ActionResult<IEnumerable<ServiceDto>> Get()
    {
        return new ServiceDto[] {
            new ServiceDto() {
                Name ="Development",
                Uri="https://readify.net/services/development/",
                IconUri="https://readify.net/media/1187/development.png"
            },
            new ServiceDto() {
                Name ="Innovation and Design",
                Uri="https://readify.net/services/innovation-design/",
                IconUri="https://readify.net/media/1189/light-bulb.png"
            },
            new ServiceDto() {
                Name ="Data and Analytics",
                Uri="https://readify.net/services/data-analytics/",
                IconUri="https://readify.net/media/1184/data.png"
            },
            new ServiceDto() {
                Name ="DevOps",
                Uri="https://readify.net/services/devops/",
                IconUri="https://readify.net/media/1188/devops.png"
            },
        };
    }
}

public class ServiceDto
{
    public string Name { get; set; }
    public string Uri { get; set; }
    public string IconUri { get; set; }
}

We aren’t securing our new API just yet. We need to make sure the API is actually working first, before we add security over the top of it.

Start the site and browser to http://localhost:5000/api/services and confirm you see a JSON result (use your browsers developer tools to see the network trace).

Securing the API

Great! Now that we’re happy our insecure version works, let’s secure the API!

Being by adding the IdentityServer4.AccessTokenValidation package from NuGet

Install-Package IdentityServer4.AccessTokenValidation

In Startup.cs add the following lines to the end of the ConfigureServices() method:

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddIdentityServerAuthentication(options =>
    {
        options.Authority = "https://localhost:5443/";
        options.RequireHttpsMetadata = true;
        options.ApiName = "api1";
    });

If you’re missing references, you may need to manually add some using statements: using System.IdentityModel.Tokens.Jwt; and using Microsoft.AspNetCore.Authentication.JwtBearer;

In the Configure() method we need to add a call to UseAuthentication() before we UseMvc().

While we’re here changing code and since we’re not supporting HTTP we can remove the HttpsRedirection call. We can also remove HSTS for now, as we’re not going to production with this code and we don’t need the hassle that HSTS adds just yet.

The Configure method now looks like the following:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseAuthentication();
    app.UseMvc();
}

At this point authentication is configured, but we don’t actually check it anywhere.

Let’s tell ASP.NET that our /api/services route is meant to be secure.

Add the [Authorize] attribute to the controller class definition

    [Route("api/[controller]")]
    [ApiController]
    [Authorize]
    public class ServicesController : ControllerBase
    {
        //...

If the [Authorize] attribute isn’t resolving, check that you have using Microsoft.AspNetCore.Authorization; included at the top of your file.

Start the application again and you should now find that any attempt to browse to the /api/services URI will return a HTTP 401 Unauthorized response, while calls to /api/values will still work as expected.

Excellent!

Unfortunately at this point it will now become a bit tricky to manually test that the authentication is working.

We would need a known client application to connect to IdentityServer with, we’d need the identity token it would return, and we’d need to attach that as the Bearer token authentication for each call to the API.

We should probably just go ahead and build the client app now, right?

I agree! Let’s forge ahead with part 5

Up Next: Part 5 - Creating the Vue.js client

Securing a Vue.js app and API with IdentityServer - Part 3

Mon, 12 Nov 2018 00:00:00 +0000

This is part 3 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer
Part 3 - Adding Google Authentication to IdentityServer (this post)
Part 4 - Creating and securing an ASP.NET Core Web API
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js
Part 7 - Securing a router view in Vue.js
Part 8 - Calling a secured API from Vue.js
Part 9 - Refreshing identity tokens with Vue.js

Adding Google authentication to Identity Server

If it’s not already open, open the IdentityServer project we created in the previous parts. Navigate to line 26 of Startup.cs and you’ll see code to configure default authentication using a standard username and password approach (.AddAuthentication()) as well as for Google and a 3rd party OpenIdConnect provider.

We’re not going to use the 3rd Party OpenId Connect provider, so go ahead and delete that code.

The Google ClientId and Secret values in the Quickstart are default ones provided by the IdentityServer team and are great for learning concepts, but not for running your own identity provider. We’re going to create our own ClientId and Secret.

Authenticating your app with Google

Begin by logging in to the Google Developer Console - https://console.developers.google.com/ and creating a new project in the Google APIs section.

When the creation operation completes you should be on the API Dashboard. Go directly to the credentials area.

As a first step we need to configure the OAuth consent screen. Set the Application Name to Vue API Demo and save the changes.

From the Credentials tab, click the Create Credentials drop down and select the OAuth client ID option

Choose Web Application and provide a name of your choice.

Set the Authorised Redirect URIs to https://localhost:5443/signin-google and then click Create. Note that this URL must be /signin-google from the base URL of your IdentityServer instance.

You’ll now be shown your Client Id and Secret.

These are the details you need to update in your IdentityServer configuration. Your code in Startup.cs should now look something like this:

services.AddAuthentication()
    .AddGoogle("Google", options =>
    {
        options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;

        options.ClientId = "1005450161824-hqg5jq2qnplaskfnjcor4erfb5m8g0rs.apps.googleusercontent.com";
        options.ClientSecret = "tPVjh2YwCxdeQjRUB0La_FPd";
    });

There’s one final step before you move on. You need to enable the Google+ API in the Developer Console.

From the Dashboard add an API and select Google+.

Now you should be set to go. Give it a try!

Start IdentityServer and navigate to https://localhost:5443/grants. Log in using your Google account, or use one of the pre-configured demo users (i.e. bob or alice, with a password of password).

Brilliant! We’ve now got an API, and a basic IdentityServer running, with support for Google SignIn.

Up Next: Part 4 - Creating and securing an ASP.NET Core Web API

Securing a Vue.js app and API with IdentityServer - Part 2

Sun, 11 Nov 2018 23:30:00 +0000

This is part 2 of a series showing you how to secure a Vue.js app with IdentityServer and call an ASP.NET Core Web API.

Part 1 - Overview and Solution Structure
Part 2 - Creating and Configuring your IdentityServer (this post)
Part 3 - Adding Google Authentication to IdentityServer
Part 4 - Creating and securing an ASP.NET Core Web API
Part 5 - Creating the Vue.js client
Part 6 - Calling an HTTP API from Vue.js
Part 7 - Securing a router view in Vue.js
Part 8 - Calling a secured API from Vue.js
Part 9 - Refreshing identity tokens with Vue.js

Creating and configuring your Identity Server

IdentityServer is an open-source OpenID Connect and OAuth 2 framework. It’s not an out-of-the-box solution. It means it’s highly flexible, but that it also requires some extra effort from us to get it working.

Thankfully, the IdentityServer team has provided some immensely useful Quickstart templates to help people like you and me to get up and running quickly. Handy!

Start by cloning the repository at https://github.com/IdentityServer/IdentityServer4.Samples and then copy the QuickstartIdentityServer folder from Quickstarts/7_JavaScriptClient/src/QuickstartIdentityServer/ into your solution root.

In Visual Studio, add an existing project to your solution and reference the Quickstart folder you just created.

The IdentityServer Quickstart projects will listen on port 5000 using HTTP, not HTTPS, by default. Port 5000 will clash with the port we’re using for our web API application and we want secured communications so we need to adjust some properties.

In the project properties page, change the Debug profile to use HTTPS on a different port number. Personally, I prefer to use Kestrel for local development and I don’t like the browser being auto-launched, so I’ve set my properties page as follows:

You can adjust your configuration to suit your personal preferences. Just keep in mind that I’ve configured IdentityServer to run on https://localhost:5443.

If, like me, you use Kestrel to run your app then you’ll want to quickly upgrade the Quickstart from .NET Core 2.0 to .NET Core 2.1.

Doing so avoids the need to manually configure HTTPS support. You’ll only need to change the NuGet reference from Microsoft.AspNetCore.All to Microsoft.AspNetCore.App and you’ll be set to continue.

Client Configuration

In IdentityServer “clients” are the client applications connecting that want to connect to a secured resource. Our Vue.js application will be one of those clients applications and will use the Implicit grant flow to authenticate.

Firstly, find the Quickstart’s JavaScript client configuration in Config.cs (you should see it at line 88).

Recall that our web application is going to be running on port 5000? When IdentityServer authenticates a person it will make a callback request to the client to complete the sign in process.

We need to tell IdentityServer the URI of this callback endpoint. We’ll also adjust the ClientName so that the sign-in process looks a little nicer in the UI.

// JavaScript Client
new Client
{
    ClientId = "js",
    ClientName = "VueApi JavaScript Client",
    AllowedGrantTypes = GrantTypes.Implicit,
    AllowAccessTokensViaBrowser = true,

    RedirectUris = { "https://localhost:5000/callback" },
    PostLogoutRedirectUris = { "https://localhost:5000/" },
    AllowedCorsOrigins = { "https://localhost:5000" },

    AllowedScopes =
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile,
        "api1"
    },
}

The Redirect URI will be a route we create (later) in our Vue.js app and is where we’ll handle the IdentityServer callback.

P.S. In case you missed it, we also changed from http:// to https:// in the URIs other URIs on the page.

Check your code compiles and that your IdentityServer starts. You won’t be able to do too much just yet, but you should be able to log in using the preconfigured users Bob and Alice, each with a password of Password.

One final note; I prefer using dotnet watch run from the specific project folders (not the solution root) to run both the IdentityServer and API applications. If you prefer running from Visual Studio, don’t forget to change the startup project or to manually start the specific projects as we go through the series.

Up Next: Part 3 - Adding Google Authentication to IdentityServer