What we're going to build in this post:
- Azure web job, which is triggered by a queue message from a custom site template (previously known as site design). The job uses PnP Framework to provision a new site based on the PnP template.
- MS Teams bot, which pushes notifications to the configured channel about the provisioning state.
As usual, for such "code-behind posts", the sources are available under GitHub here.
This is how the approximate solution looks like:
Cosmos database contains notification settings. It includes channel id (the channel, which receives notifications about provisioning state), service URL (we use this URL to send proactive messages to, can be obtained from bot activity), and tenant id (optional). PnP provisioning reads the database and proactively pushes notifications using bot credentials to all configured channels. More...
As a developer, how many times have you had a need to test different Microsoft 365 APIs? For me, this is a fairly frequent task. Most often it's SharePoint REST API or MS Graph. Every time you should think about the authentication part because all of those APIs are protected. With MS Graph explorer it's simple, however, you cannot test any other API except the MS Graph. Also, sometimes you have access to different customers environments or tenants and it's not that simple to easily switch between them, handle authentication, and so on.
I ended up testing everything in Postman using a generic approach, which works for any Azure AD-protected resource. This approach uses OAuth2 Auth code grant flow (or Resource Owner Password Credential flow, ROPC, also covered in this post), it stores tokens and automatically renews access tokens for a resource if this particular token is expired. This approach involves custom Azure AD app registration for Postman, Postman's environments feature, environment and collection-level variables, pre-request scripts.
Read further below to find out how I configured it. My approach is not a silver bullet, but at least it works for me. You can grab some ideas and adapt them to your requirements. More...
Sometimes you have a need to call an Azure Function with Azure AD enabled authentication from Logic App or from another Function or Azure Web App. For example, you have an API for your SPFx solution and also have a requirement to build a Logic App, which uses some methods from the web API. In that case, you should somehow perform the authentication to call your Azure AD protected function. You can easily solve this problem with Managed Identity.
Let's see how it works in practice. More...
In this post, I'm going to cover different options when it comes to accessing organizational data from SPFx web parts. By organizational data I mean the most common APIs like SharePoint or MS Graph. However, it's valid for all other APIs as well.
I'm going to cover two primary options here. The first one doesn't include any custom services or custom APIs and relies solely on SPFx OOB functionality. In the second option, we use Azure Function as a custom Web API component to access organizational data. As a bonus, we also have the third one which is a combination of the first two. More...
This post challenge:
We have an SPFx solution, which performs HTTP calls to our API (protected with Azure AD authentication), hosted on Azure Functions. From Azure Function we further call SharePoint endpoints to get some data. We use PnP Core SDK to interact with SharePoint. For simplicity, the API endpoint returns all list titles in a web, where we're runnning our SPFx web part.
Why PnP Core SDK? Because it's the future of PnP Sites Core library. PnP Core SDK uses a modern .NET development stack and built from the ground up to better support different types of apps, to be cross-platform, fully tested, and maintainable. Read more on the documentation here. Also, Beta1 of the PnP Core SDK was released recently, so it's a good chance to explore it! More...
You have a custom SharePoint Site Design, which executes (through MS Flow or Azure Logic App) PnP Provisioning process. You want to notify users that the site is not fully ready yet and it's still being updated (by background provisioning, which might take a long time). One option is to use two-way interactive communication between the SharePoint web site and the job using SignalR. That's something we're going to explore in this post in great detail.
Check out below short video, which demonstrates the resulting UX we're building in this post:
The video was cut because the actual process takes 7-9 minutes on my tenant.
Read further below to find out how to setup everything from scratch.
All sources, as well as brief configuration steps, are available at the GitHub repository. More...
SPFx 1.6 was released recently and a lot of new and interesting features were introduced. AadTokenProvider, AadHttpClient, MSGraphClient went to GA, which are my favorite features. One of the common thing in SPFx development is accessing other resources, protected with Azure AD. For example you might have your LOB API with Azure AD protection and you want to consume that API from SPFx web part (extension). Before SPFx 1.6 it was a bit challenging, because you have to deal with cookies attached to your asynchronous http request or with custom “patched” adal.js implementation. SPFx 1.6 features mentioned earlier drastically simplify the task to access Azure AD protected resources. Now you can access Azure AD APIs (including Microsoft APIs like MS Graph) from SPFx with ease!
I’m pretty sure you know about PnPjs library. It has a lot of cool features, among them a fluent interface to SharePoint and Graph API. WIth SPFx 1.6 release you can use PnPjs as your Graph client without hassle. Read further to find out how. More...
Consuming third party or your own Azure AD protected API from SPFx code is a very common need. I wrote a blog post series on that topic, the first one you can find here. All solutions I covered have their own pros and cons, however the less painful and recommended solution is AadHttpClient (available in SPFx 1.6 and onwards). AadHttpClient approach has less issues and works really good. If you are curious about how it actually works, read the rest of the post. In this post I dive into AadHttpClient architecture, libraries and technologies used, think about security issues and try to bypass (spoiler: successfully) webApiPermissionRequests restrictions in SPFx web parts. More...
Call Azure AD secured API from your SPFx code series:
- 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. 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. Story #2: Web app (or Azure Function) and SPFx with adal.js
- 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:
- New app registration in Azure AD (step will be taken from previous post)
- 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)
- SPFx webpart, which uses API via AadHttpClient
- Deployment and testing
As usual, let’s get started More...