The SharePoint Framework has been generally available in SharePoint Online as of February 23rd. It is currently rolling out to all global Office 365 tenants. The new Framework modernizes the way developers build in SharePoint, and provides a great experience across both the desktop and mobile interfaces.
There is official enterprise guidance that covers off common concerns around security and deployment. In this post I wanted to highlight some scenarios as a SharePoint administrator you should be aware of.
The end user experience for adding web parts to SharePoint pages has changed. The administrator experience of deploying packages to SharePoint has changed too.
Currently the SharePoint Framework gives you the ability to add a web part to a modern page. Modern pages were announced in August 2016. This is a brand new page model with no migration path from classic pages. These web parts are different from the web parts developers built in previous models, including:
The resetting of the page model in the product and releasing a fourth development model has caused a lot of confusion for both Microsoft and customers.
I wrote this response to Chakkaradeep Chandran’s blog post on “working with the product and not against the product”. I posed the question to the community on whether they think its a new model. With 77 voters over 4 days of voting and a 79% Yes response…it seems most do.
One thing to point out here is that the add-in model is still fully supported. So you do have two options for developing with SharePoint. If some of the security scenarios mentioned below concern you, you’ll likely stay with the add-in model.
The team at Ignite talked about the new Framework coming in a SharePoint Server 2016 feature pack. It was not part of feature Pack 1 released in November 2016, nor does the SharePoint roadmap give any indication of when this is coming. The SharePoint team haven’t really indicated when the next feature pack is due either.
As an IT Pro, you’ll be receiving a new package with an extension of .sppkg from your trusty developer. There is information on dev.office.com on how these are created by developers. You’ll need to go to the App Catalog in the SharePoint Online administration pages, this is the same app catalog where you would upload add-in packages.
For scenarios where web parts have had updates from developers, you can also upload updated SharePoint Framework packages here (just like you did for add-in model).
For each site that you want these web parts available in, you’ll have to go to the ‘add an app’ page and add that packages ‘app’ (confusing yet?). The benefit for administrators, is that they can grant permissions to the package in the App Catalog for who can see it to add.
This will deploy the web parts into the web part gallery. This is the same web part gallery used for classic web parts and app parts. In classic pages, the end user will see these modern web parts like the classic web parts. This means you can apply item level security to them, so they are only available to targeted people.
The benefit of modern pages and web parts being responsive, is that they will show in the SharePoint mobile app. This is something end users have been wanting for a long time.
Another nice touch, is that modern web parts can also be added to classic pages. This will be a common scenario for SharePoint sites that are heavily using classic web parts for dashboards or intranet portals. Meaning your developers can play with the new technology and not wait for sites to be upgraded.
There is a roadmap item for the ability to add classic web parts and app parts to modern pages. The issue here is that these are not responsive and will likely break pages and not work as expected on mobile devices.
Microsoft will be working hard to build modern web parts and modern page features that will compel users to replace the classic pages. Right now, there is a lack of modern web parts available and no ability to brand modern pages.
Modern pages right now are also limited to one column, this is highly restrictive for intranet portals or dashboard scenarios. Web part zones were a great way to have multi column layouts in SharePoint pages. Jeff Teper did state at Nintex InspireX that these were coming, but didn’t give a specific timeframe on this.
This section is really highlighting the worst case scenarios. However, I think it is important to be aware from the beginning. If this is huge concern, then I would encourage you to stick with the add-in model.
The only way to get a .sppkg package into SharePoint Online is as a SharePoint administrator. Gone are the luxuries of site owners being able to upload sandboxed solutions or add-ins from the Office Store. The main reason for raising the bar to administrators only is permissions, much like the original full trust solution model. The web parts deployed on pages have full-trust access to the SharePoint APIs impersonating the user viewing the page the web part is on. There is no way to do granular permissions like the add-in model, meaning you cannot limit a web part to just read-only access to the site.
The good news about it being administrator only, is you won’t get users deploying client side code into modern pages without the visibility through the App Catalog.
Mikael Svenson has already built a script editor web part, so be on the look out for someone sneaking that into your App Catalog! This would allow them to add the web part and write client-side javascript in a modern page to do anything with the page document object model (DOM). For administrators this opens up Pandora’s box, because if you edit the DOM you can break out of the box functionality in the page.
Pat Miller from the engineering team pointed out that there is a way for developers to define web parts have scripting capabilities. This would mean if you turned on “NoScript” settings it would be blocked. The main problem here is trusting your developers to do the right thing.
The risk you run now is that someone adds a web part with malicious code to a page in a site, and sends the link to your CEO. That web part instance then has access to everything the CEO has access to through the SharePoint API. Not just the site the CEO is visiting, but all sites. There is a github issue that is being tracked for this. Unfortunately the truth is, there is no easy way to prevent this with the client-side model Microsoft have architected.
The other major risk with this is hijacking access to underlying internal APIs (or external APIs if you are an ISV). If your internal enterprise developer team build a modern web part and it accesses a internal API, it can be hijacked. The reason for this is, they are likely to have a token based authorization system to call the internal API. If a web part from an ISV is deployed to the page and discovers another web part connection to an API with a token, it could access that system as there is no isolation.
Because of the risk of phishing and hijacking, before you upload a package to the App Catalog, you will have to do your due diligence. You will have to make sure the package you are using isn’t doing anything in code it shouldn’t. For instance, you should check that the code doesn’t access APIs it doesn’t need to do its task, or that it doesn’t randomly delete or edit content it shouldn’t be touching. Sadly there is no automated way to do these checks, so a code review is required here.
When you upload a package to your App Catalog, SharePoint reads the embedded manifest files to deploy dependencies into the appropriate places. One thing to watch out for is packages that reference externally hosted files, such as external CDNs. The reason for this is, if you do your code review based on the files it references at that point in time, there is nothing stopping the author of this package from changing the files on the CDN. The developer could switch the file to do something similar to the hijacking or phishing mentioned above.
The good news here is that you can basically tell the supplier of the package to make all the files deploy within your tenant instances, SharePoint Libraries, or your CDN. This will give you the control to update their package and containing files, after an additional review.
I was extremely grateful to get an hour of Mike Ammerlaan’s time from Microsoft to talk about this in more detail. Check out the podcast here.
The new SharePoint Framework is currently v1.0 and you can expect many more features to come throughout the year. There are a lot of gaps that need filling between the SharePoint Framework and existing models. It will be interesting to see how Microsoft prioritize the scenarios based on customer feedback on GitHub.
The team at Microsoft are doing a great job of keeping people informed on this through the Patterns and Practices initiative. Check out the SharePoint developer center here https://dev.office.com/sharepoint.