Call Azure AD secured API from your SPFx code series:

1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials")
2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials") <—you are here
3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js
4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

In the previous post, I showed an example on how to call Azure Functions API protected with Azure AD (using EasyAuth setup). Described approach has a few limitations, one which is the most important is an inability to send HTTP POST or PUT requests. This issue can be fixed by using regular ASP.NET Web API application with custom authentication layer. More info about this approach you can find here - Access the API by leveraging SharePoint Online authentication cookie. This post describes required steps to make it work:

1. Add new app registration in Azure AD
2. Create new ASP.NET Core application and setup authentication with Azure AD.
3. Enable CORS for your web application with credentials support (so we can send CORS AJAX and attach credentials to our request, auth cookie in our case)
4. Create simple SPFx webpart, which gets data from our web app via authenticated HTTP request (GET and POST).

The source code for this article available on GitHub here.

Let’s get started. More...

Call Azure AD secured API from your SPFx code series:

1. Call Azure AD secured API from your SPFx code. Story #1: Azure Functions with cookie authentication (xhr "with credentials") <—you are here
2. Call Azure AD secured API from your SPFx code. Story #1.1: Azure Web App with ASP.NET Core 2.x and cookie authentication (xhr "with credentials")
3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js
4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

Imagine a very common scenario, when you need to send HTTP request to your backend API to get or store some data from your SPFx web part. Of course, you can’t leave your API without any authentication layer. Using Azure AD authentication for that matter is a very good choice because you leverage SSO within your organization. The question is, how to properly get an access to those API in a secure and seamless manner. One option might be using cookie authentication. This approach doesn’t use well-known library adal.js, at the same time it’s simple, however, has its own cons (read at the end of the article). More info about this approach you can find here -  Access the API by leveraging SharePoint Online authentication cookie. In another post, I will show how to do the same thing using SPFx’s AadHttpClient.

We are going to perform below steps:

1. Create a simple Azure Function in Visual Studio.
2. Create Function App and deploy our code to the Function App in Azure Portal.
3. Create new App Registration in Azure AD.
4. Setup Azure AD authentication for Function App.
5. Create simple SPFx webpart, which gets data from our Azure Function via authenticated HTTP request.

Let’s get started. More...

Basics

SPFx has a built-in mechanism, which holds some configuration values for you. For example in runtime, you can read them and determine if you are running locally or not. You can verify if you are in debug mode or not. You can do some other things as well. Let’s take a closer look at some values, available out-of-the box.

Probably you know, that SPFx build pipeline is webpack based. It means, that webpack’s configuration supplies a lot of those values. The most useful are:

• process.env.NODE_ENV - can be either ‘production’ or ‘dev’ depending on an environment where the code is running
• DEBUG – boolean, equals to false for release builds and true for development
• DATACENTER – boolean, equals to true if you are running in context of SharePoint Online. Might be useful if you build webparts for on-prem and Online at the same time More...

A few weeks ago I’ve created an issue around Webpack 2 support for SPFx build pipeline. And there are some good reasons why it’s a good idea to use webpack 2 in SPFx:

• webpack 1 is deprecated
• documentation for webpack 2 is better
• webpack 2 schema more understandable
• sometimes webpack 2 faster (it depends, but still)
• all core webpack loaders supports version 2 and might have issues with previous version down the road
• SPFx introduced as a framework which supports modern web technologies and tools. Someone use Angular, React, someone Vue.js. Vue.js uses webpack 2 and it’s more natural to use webpack 2 with Vue when building SPFx web parts

Finally a few days ago SPFx team released a new version which built with webpack 2! And that’s a good news.

I had to fix all samples around Vue.js and SPFx, because webpack schema is changed. But now I personally feels more comfortable about extending SPFx with Vue.js, because at least they are using the same version of bundler.

Please checkout updated samples with Vue.js in official repository here - https://github.com/SharePoint/sp-dev-fx-webparts/tree/master/samples/vuejs-todo-single-file-component and experimental sample where everything in .vue file (including TypeScript code) - https://github.com/s-KaiNet/spfx-vue-sfc-one-file

Vue.js becomes more and more popular and it’s time to build real life sample using Vue’s single-file components. Single-files components are the building blocks for Vue application. It’s not required to use single files components for Vue application, but they give you some advantages:

• recommended style for Vue applications
• modern components-based approach
• good separation of concern between markup, css and code
• we don’t need to use standalone version of Vue and can use runtime version, which is smaller
• since we are using runtime version of Vue, our app works a bit faster, because not need to compile templates (already compiled by vue-loader)

Original sample can be founded under SharePoint Framework client-side web part samples – that’s a basic todo web part built with Vue. This a companion post describing some concepts.

The most difficult part is to setup our SPFx build pipeline to support Vue. Here are the steps required in order to make SPFx vue-compatible: More...

What is Vue? One can say that’s just another js framework but that’s not true. Vue.js is a progressive framework for building user interfaces for web. Now days it’s not so popular as Angualr and React, but community growing extremely fast and some bloggers predict that Vue in 2017 will be as popular as Angular or even React. Main github repository has 42K stars on a moment of writing, for comparison angular 1 has 58K and angular 2 only 20K. For me Vue looks very very promising and it’s definitely good reason to take a look at this framework. In this post you will see how to create very basic client web part with Vue.js. Let’s get started.

Create new empty directory and run

yo @microsoft/sharepoint

In the end select “No Javascript Framework”. More...

Sometimes you need to adjust SPFx build pipeline a bit, in order to add your own webpack loaders or modify configuration for some tasks. This can be done in different ways depending on your needs. Let’s try to take a closer look at the options available.   Below is a diagram showing common config flow with extensibility points:

There are two places where you can put your customizations – under custom task’s config adjustments or using configuration file under config/[task name].json during loadCustomConfigs() method. More...