SharePoint Framework Web Parts are hosted externally. But how do you tell where exactly and how well they are governed?
The anatomy of SharePoint Framework customizations
SharePoint Framework customizations consist of two main pieces: the code, hosted on a location accessible via a URL, and the manifest deployed as an .spapp package. The manifest registers SharePoint Framework Web Parts with SharePoint and instructs it where to download the particular Web Part from. Whenever you add the particular Web Part to the page, SharePoint Framework will call the specific URL, download Web Part’s code including referenced resources, and execute the script in the context of the current user. Whatever the user can do, the Web Part can do as well. So how do you tell if you can trust the particular Web Part or not?
It’s SharePoint all the way
In the past, when building SharePoint customizations, we strove to have our customizations integrated with SharePoint as much as possible. SharePoint was a platform and our customizations reused as much of it as possible. Deploying customizations that required external components, like services or databases was considered a bad practice.
Separate is the new together
Fast-forward to today, many organizations use SharePoint hosted as a service as a part of their Office 365 subscription. Because Office 365 is running on shared infrastructure, organizations are not allowed to deploy their server-side components to customize SharePoint. Such customizations threathen the hygiene and stability of the servers hosting SharePoint and a failure in one of them could affect many organizations.
In the past already Microsoft provided us with an extensibility model that we could use to customize SharePoint both on-premises and in the cloud. Using SharePoint Add-ins we could build customizations that communicated with SharePoint using its remote APIs. Comparing to Farm Solutions, which usually ran under the permissions of the current user, SharePoint Add-ins were locked by the specific permissions granted to them during the installation. This allowed organizations to control which operations the particular add-in was allowed to perform.
The recently released SharePoint Framework is a new model for customizing SharePoint that helps developers build richer business solutions. Similarly to SharePoint Add-ins, solutions built on the SharePoint Framework communicate with SharePoint using its remote APIs. What’s different however, is that SharePoint Framework solutions are built using JavaScript, hosted externally and run in the context of the current user. Here is why you should keep this in mind the next time you will be deploying SharePoint Framework customizations.
New model but not a new concept
The concept behind the SharePoint Framework isn’t new. For years developers have been adding scripts to pages using Content Editor Web Parts to customize SharePoint. Just like with the SharePoint Framework, these scripts were a part of the page and ran in the context of the current user. The added value of using SharePoint Framework for building similar customizations, is that it standardizes how we integrate our customizations with SharePoint and load external scripts.
What you should consider before deploying your next SharePoint Framework solution
When deploying SharePoint Framework customizations to your SharePoint tenant most likely all you would get is the .spapp file with the Web Part manifest. The manifest would point to the location where the Web Part’s code has been deployed. Being responsible for your organization’s SharePoint environment and given the fact that the Web Part’s code will be able to do whatever the particular user using that Web Part can, there are a few things that you should know before you deploy the .spapp package to your SharePoint tenant.
First and foremost, you should know where the code of each Web Part is located and what the policy around updating it is. You should know if that location is owned by your organization or by the vendor who provided the Web Part. You should know who can access that location and what the policy is around updating the Web Part’s source. Are silent updates, where new functionality or bug fixes just appear the next time users open the page, allowed or is every update approved and confirmed by releasing an updated version of the .spapp package pointing to the updated scripts? You should know what the SLA of the storage location hosting these Web Parts is and how well it matches your organizational needs. Finally, you should know where the different Web Parts used across your intranet are located and if all these locations are approved by your organization.
Keeping track of where the different Web Parts used throughout the intranet are stored is tedious. A solid governance plan is essential to ensure that your organization controls the customizations your users are working with. But a plan is not enough. For the plan to work, you have to have an easy way to enforce it. The only way to find out where every Web Part is located is by examining the contents of the .spapp file, locating the Web Part’s URL and all its dependencies: some of which are listed in the manifest but some of which might be loaded in code. With your intranet using tens or hundreds of Web Parts, it might takes days or weeks to verify that all elements meet your governance requirements.
Taming SharePoint Framework customizations with SPCAF
SharePoint Code Analysis Framework (SPCAF) helps you gain insight into where the different SharePoint Framework customizations are hosted and what dependencies they are using. All you need to do is to drag and drop an .spapp package onto SPCAF and once the analysis completes, you will see the hosting location and structure of Web Parts in that package.
Manual analysis is helpful but the true added value of using SPCAF is by setting it up as a deployment quality gate. Assuming you have automated the deployment of your SharePoint customizations, after adding a new customization to the queue you would have it verified by SPCAF. Having defined a white-list of approved hosting locations for Web Parts, in a matter of minutes SPCAF would provide you with a report listing any Web Parts stored outside of your approved locations.
Before deploying the customization to your SharePoint tenant, you could have it examined closer and contact the person responsible for it to discuss further details. Instead of spending hours searching for a needle in the haystack you could immediately focus on the specific issue not complying with your organization’s governance plan. SPCAF saves you time and helps you govern your SharePoint customizations more effectively.
SharePoint Framework solutions better with SPCAF
SharePoint Framework is a new model for customizing SharePoint. It’s built upon a different set of principles than other SharePoint customizations models available to date. SharePoint Framework introduces new governance challenges that organizations have to include in their plans to maintain the security and integrity of their intranets. Based on our experience with the SharePoint Framework, that we gained since its early beta versions, we implemented a set of rules that we are confident will help organizations build and use SharePoint customizations built using the SharePoint Framework. SPCAF gives you actionable insights that you can use to enforce your organization’s governance plan and ensure the integrity and security of your SharePoint environment.
