You might experience errors when first trying new SPFx 1.6 features

SPFx 1.6 was released recently with new features which support secure connection to Azure AD protected APIs. During upgrade some things in your tenant and Azure AD were changed. For some users migration didn’t go smoothly and they saw strange errors in different places. I’m in the group of users who experienced errors and had to fight with them. Fortunately really smart guys from Microsoft and community resolved everything. There are a few issues on GitHub related to SPFx 1.6 errors. It might be difficult to go through all comments and find an answer on your concrete problem. I see that more and more people struggle with the same types of errors, I sum up potential errors and their resolutions in a separate post.

Basically there are two types of errors you might see when trying SPFx 1.6 features. They are described at GitHub SPFx The user or administrator has not consented to use the application with ID and SPFx suddenly stopped working; experimental feature error.

NOTE: after you have applied fix(es) you should redeploy and reapprove your permission requests.

Issue #1

Error messages:

When open a webpart, which uses SPFx 1.6 features (MSGraphClient, AadHttpClient, etc):

Uncaught (in promise) Error: The requested operation is part of an experimental feature that is not supported in the current environment.

When open SharePoint Admin center (modern) and go to API Management page:

Access to Azure Active Directory resources using the SharePoint Framework will be available soon.

You also see below popup at API Management page:

Additionally on the same page you see a set of errors:

A null value was found with expected type 'Edm.String[Nullable=False]. The expected type does not allow null values.

With below picture:

Cause

For new features to work from admin center, your user should be a site collection administrator at SharePoint admin site collection. The funny thing is, if you have only one user in your whole tenant, you might no be a site collection admin at administration site collection. To check that you 100% experience this issue, just open a page with url https://yourtenanthere-admin.sharepoint.com/_layouts/15/settings.aspx. See “Access denied”? – You are not an admin.

Fix

You can fix it using different ways.

Manual (UI) way:

  1. Go to the user page in the Microsoft 365 admin center (admin.microsoft.com/adminportal, then select Users->Active Users)
  2. Click Add A User
  3. Complete the information, and make sure that you set the License to be "SharePoint Online For Developer" and set the Role to be "Customized Administrator" with "SharePoint Administrator" selected.
  4. Click "Add".
  5. This might take a while....
  6. Log in to the SP admin center as this new users (tenant-admin.sharepoint.com)
  7. Go to _layouts/15/settings.aspx and select "Site Collection Administrators" under Users and Permissions
  8. Delete the incorrect user (hit the X, even if the UX is spinning)
  9. In the little text box, enter "Company Administrator", select the Company Administrator when it resolves, then click "OK". Note - at this point you may get an access denied. Ignore it.
  10. Now log back on with the tenant admin, and hit the API page.
  11. If this is all working, you can delete the user you added.

PowerShell (you need the SharePoint Online Management Shell) way:

Connect-SPOService
Set-SPOUser -Site https://TENANT-admin.sharepoint.com -IsSiteCollectionAdmin $True -LoginName yourLoginName

Issue #2

Error messages:

You see this error in a console on a web page, when running your SPFx 1.6 web part:

The user or administrator has not consented to use the application with ID '<guid>' named 'SharePoint Online Client Extensibility Web Application Principal'. Send an interactive authorization request for this user and resource.

Or this one:

Error: AADSTS90008: The user or administrator has not consented to use the application with ID '<guid>'. This happened because application is misconfigured: it must require access to Windows Azure Active Directory by specifying at least 'Sign in and read user profile' permission.

Cause

If you want to use any API from Microsoft (MS Graph or other APIs), you should add permission for those APIs. It appeared, that you also have to provide permissions to Windows Azure Active Directory principal ('Sign in and read user profile'). Why it’s needed? Probably because all Azure AD protected APIs use Windows Azure AD under the hood and minimal permissions are required.

Fix

There are two ways to fix it. From Azure AD side and from your web part’s manifest side.

Official documentation hasn’t updated yet, however it seems that correct way to do it with a new entry in webApiPermissionRequests:

  1. Open your package-solution.json file.
  2. Add new entry:
"webApiPermissionRequests": [
 {
   "resource": "Windows Azure Active Directory",
	"scope": "User.Read"
 },
 // your other permission requests
]

   3. Deploy, approve your app and you are good to go. You should include it for every web part which uses webApiPermissionRequests feature.

Another option (seems less official, however you can do it once for whole tenant):

1.    Head over to the App Registrations Page in the Azure Portal.
2.    Click "View all applications"
3.    Click "SharePoint Online Client Extensibility Web Application Principal"
4.    Choose "Settings" > "Required Permissions"
5.    Click "Add"
   -    "Select an API" and choose "Windows Azure Active Directory", press "Select"
   -    "Select Permissions" and choose "Sign in and read user profile", press "Select"
6.    Click "Done"
7.    Click "Grant permissions" and "Yes"
8.    Update the app package in the app catalog
9.    Head back to the "API Managment"-section:
   -    Ensure that "Windows Azure Active Directory" is already listed in the approved permissions (this permission should be here because of the previously executed steps).
   -    Approve all permission requests one by one. Once this is done, reload the page to ensure that all permissions are actually approved as the SharePoint UI doesn't always behave as expected.
10.    Wait a couple of minutes
11.    Log out of SharePoint, close all browser windows and log in again
12.    Access your intranet and everything should be fine

Basically that’s it. Happy fighting Smile.