Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

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")
  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 <—you are here

This post covers the last and recommended way to interact with remote Azure AD protected APIs from SPFx code – AadHttpClient. As of now (Aug 2018) this feature is still in preview and not available for production. I guess it will be available in a few months, however that’s only guessing. Why it’s recommended? Because it’s OOB SPFx way to interact with APIs, it eliminates almost all cons we have with previous methods and it’s much simpler and solid. More info on this topic you can read here - Connect to Azure AD-secured APIs in SharePoint Framework solutions.

Source code for the post is available here at GitHub.

Today’s post covers:

  1. New app registration in Azure AD (step will be taken from previous post)
  2. Create Azure AD secured API (Web App with custom jwt bearer authentication or Azure Function with EasyAuth aka App Service Authentication, I will cover both) and enable CORS (step will be taken from previous post)
  3. SPFx webpart, which uses API via AadHttpClient
  4. Deployment and testing

As usual, let’s get started Smile More...

Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js

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")
  3. Call Azure AD secured API from your SPFx code. Story #2: Web app (or Azure Function) and SPFx with adal.js  <—you are here
  4. Call Azure AD secured API from your SPFx code. Story #3: Web app (or Azure Function) and SPFx with AadHttpClient

It’s possible to call your remote Azure AD secured API with help of popular adal.js library. This approach has a number of issues (read in the end of the post). Almost all issues come from a fact, that adal.js works well in case of SPA and doesn’t play nicely in SPFx world. To make it work with SPFx, you should “patch” it. Even in this case there are some caveats. That’s why for now recommended approach is using AadHttpClient, however for the sake of completeness I wrote a post on adal.js as well. By the way, AadHttpClient is still in preview (as of now, check the actual state at docs.microsoft.com).

Read more on this topic here – Connect to API secured with Azure Active Directory and here – Call the Microsoft Graph API using OAuth from your web part.

In today’s post we need to perform below steps:

  1. Add new app registration in Azure AD
  2. Create Azure AD secured API (Web App with custom jwt bearer authentication or Azure Function with EasyAuth aka App Service Authentication, I will cover both) and enable CORS
  3. Patch adal.js library to work with SPFx
  4. Create SPFx web part, which uses adal.js and calls remote Azure AD protected API

The source code for this article available on GitHub here.

Let’s get started More...

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")

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. Story #1: Azure Functions with cookie authentication (xhr "with credentials").

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...

Read and manipulate SPFx configuration values in your code like a boss

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...

SharePoint Rest API Metadata Explorer: the present and the future

A few days ago I published SharePoint REST API Metadata Explorer. In this post I want to share a bit more information about it and share future plans as well.

The Present

SharePoint Rest API for long time was a hidden gem for me. I used CSOM or JSOM without issues and that was fine. Nowadays the power of SharePoint REST API increases. Today REST is a recommended way to interact with SharePoint. BTW for a browser there is a great library to manipulate SharePoint REST API using convenient fluent syntax – PnPjs. If you haven’t tried it yet, it’s time to try Smile.

What is always difficult for me with REST API – to find good documentation for different REST API url along with good usage examples. Some information available at docs.microsoft.com, some in blogs and sharepoint.stackexchange site. However there are few issues with mentioned sources:

  • they don’t fully cover REST API, there are still a lot of methods which are not yet covered
  • in SharePoint Online every month REST API changes and new methods or method params appear

A few years ago I discovered that SharePoint REST API provides WCF $metadata endpoint. More...

PnP-JS-Core (aka sp-pnp-js) VS @pnp/* (aka PnPjs)

I bet you know fairly popular PnP-JS-Core library. It also known as sp-pnp-js, because the original file and corresponding module in npm called sp-pnp-js. Home page on github advertise it as “JavaScript Core Library” (using analogy to PnP-Sites-Core). However today there is another (very similar) library at pnp/pnp (or PnPjs) which looks very similar. What is the purpose of this new library? Should I use it or continue using old PnP-JS-Core?

Actually for now these libraries are identical and have feature parity. What is the purpose of having two identical libraries? Because PnPjs is an evolution of original PnP-JS-Core. Consider below points regarding new library:

  • new organization name (github/pnp) corresponds to npm modules names (@pnp/)
  • new library has better structure organization – there are multiple logically divided modules, thus making support and extensibility easier
  • new library has exactly the same API and features as current PnP-JS-Core
  • new library is a part of SharePoint Pattern & Practices (SharePoint PnP)
  • the same people are behind it – Microsoft and awesome community
  • development will be performed simultaneously in two libraries for about 5 months. If one feature is available in PnP-JS-Core, this feature also will be added to PnPjs (and vice versa)
  • after 5 months (approximately summer 2018) PnP-JS-Core will be deprecated, it will be available in npm and cdn, however it will never receive new features, because main development will be transitioned to PnPjs (pnp/pnp)

What does it mean for you? If you are starting a new project, use new PnPjs library. If you have a chance to perform an upgrade for your current project, upgrade it to PnPjs. If you have a project with PnP-JS-Core – its fine, because the library will be in npm and on cdn, however new feature won’t be rolled out starting from summer 2018 for PnP-JS-Core specifically.

To listen about upcoming changes checkout PnPjs community call – starting from 19:00. If you want to listen to community calls live – use this calendar invite.

Hope this helps!

VSTS stories. Upload file to SharePoint from Gulp as part of your build definition.

Last time I blogged about a way to run PnP-PowerShell from VSTS build. This time I’m going to demo on how to run various gulp tasks interacting with SharePoint (upload file for example). Of course, you can easily do that with PnP-PowerShell, however what if you utilize gulp heavily and want to keep everything in one place. Or file upload is a part of your other gulp-based process. Anyway, there might be cases when you want to do that, and here is how.

Start with a new build definition “empty process”. Refer to previous blog to find out how. For our process we need only two simple steps: More...

VSTS stories. Running PnP-PowerShell scripts as part of your build definition

Visual Studio Team Services (VSTS) is a great way to build and manage the process of building software. If you don’t know what is VSTS, here is a quote from the official docs site:

VSTS is a cloud service for collaborating on code development. It provides an integrated set of features that you access through your web browser or IDE client, including:

  • Git repositories for source control of your code
  • Build and release management to support continuous integration and delivery of your apps
  • Agile tools to support planning and tracking your work, code defects, and issues using Kanban and Scrum methods
  • A variety of tools to test your apps, including manual/exploratory testing, load testing, and continuous testing
  • Highly customizable dashboards for sharing progress and trends
  • Built-in wiki for sharing information with your team

VSTS has a great support for setting up and running CI\CD processes. As part of your CI build definition it’s possible to run PowerShell script as well. And it’s also possible to run PnP-PowerShell scripts, however a few adjustments required.

In today’s post I’m going to describe how you can configure your CI build process to run PnP-PowerShell script. More...