Introduction
Isolated web parts are used to securely communicate with API secured in Azure AD, without sharing the access token with other components. In this blog, we are going to view how the isolated web part work and the common limitation of this web part.
How isolated web parts work
This web part will run on a unique domain and it will be hosted in an iframe. The web API permission granted to this application only applied to this app unlikely of the older version. A dedicated Azure app will be registered in the Azure portal with the specified permission.
How to create the isolated web part
Steps to create this web part are similar to the previous version Spfx web part. The property to differentiate the domain web part is isDomainIsolated:true which is available in config/package-solution.json. Yes! You are correct this is the same file we specify our web API permission too. (Hmm! quite easier to remember).
For this blog, have created a webpart to print the display name and Email address of the O365 group which require the graph permission "Group.Read.All". Once the solution is deployed and approved, you can clearly view the isolated permission in the API access tab.
Limitations
- Debugging the webpart in VS code - We are using the “Debugger for Chrome” extension in VS code to debug the web part. On the first run, you may experience the error. (Well, I did!)
Error - Type: interaction_required - Description : AADSTS65001: The user or administrator has not consented to use the application with ID ‘XXXXXXX-XXXX-XXX-ba93-a93efa079f04' named 'SharePoint Online Client Extensibility Web Application Principal'. Send an interactive authorization request for this user and resource.
So, what is the error? This message shows the application has not consented to use the permission. (Hmmm! that is not correct, I just granted permission). The reason for the warning is the application is running locally and the consent granted is to use the permission in the specific domain. So the code running in local will not get the consent to utilize the API permission.
Workaround
Log in to the Azure portal -> Azure AD -> App registration -> Find the app “SharePoint Online Client Extensibility Web Application Principal” and grant permission which is mentioned in your package. Bang! You can use the application now to debug it in local….
People! Let's wait this is a workaround to debug. However, ensure this permission is removed once after the development is completed because this will enable the organization-wide access.
- Multiple Login Issue
As a developer, you may work on different environments to develop, test and fix issues like dev, SIT, pre-prod and so on. When we work on domain web part, as described earlier it will run in iframe from different domains. SharePoint will silently login to this domain if you are in a single tenant.
What will happen if you log in to different tenant in the same browser? You may end up with the below error.
This error will occur due to the multiple logins from different tenant or multiple account logins from the same tenant. In this scenario, domain iframe do not know which account it should take for login. Hence, it may end up with the error. It could be avoided by using different chrome profiles or by using incognito mode or by using logged out profile.
In the above scenario, the same browser has multiple logins.
The same webpart will work fine in different Chrome profile or incognito modes
Let me know if this is helpful! Cheers! Happy Coding!