Apr 21, 2018
In part 1 of this article, I introduced the concept for an SPFx extension that adds a header to every page, showing the classification information for a site. In part 2, we created an SPFx extension that adds a header that displays a static message with the security classification of a site.
Yes, static. As in hard-coded. I try to write these articles for people who don’t have as much experience with developing SPFx extensions, so I included the step-by-step instructions.
In this article, we’ll discuss how we use property bags to store the security classification.
Property bags is a term used when describing a serialized list of properties. It isn’t unique to SharePoint — I remember using them in the good old C days, but SharePoint has been using them for a long time. Remember this screen from SharePoint Designer?
Property bags are a convenient way to store a whole bunch of properties of things. In SharePoint, a property bag can be applied to the File, Folder, List or Web-level in SharePoint. When set at the Web level, it can be for a Site Collection or Site — at least that’s what MSDN said about SharePoint 2013.
The great thing about property bags in SharePoint is that they are attributes of their parent, which means they are protected the same way their parents are.
In theory, you could use a custom SharePoint list, add it to every site, manage the permissions, and add one row per property you want to store about each site, but that would be painful.
You could also store an XML or JSON file in every site that does the same, but then you’d have to write the code to create and store the file, protect it, and read it.
…or you could use the out-of-the-box mechanism to store metadata about a site, and let SharePoint create it and protect it. Also, you could use the countless ways to access the property bags (SharePoint designer, PowerShell, CSOM, PnP JS, Office 365 CLI, etc.).
So, for our Classification extension, we’ll store and read from the site’s property bag. To pay a homage to Microsoft’s own solution to Implement a SharePoint site classification solution, we’ll use sc_BusinessImpact for the property name. You could name it anything you want, but you probably want to keep it somewhat unique.
Here is what the property bag looks like in SharePoint Designer 2013:
In the previous article, I asked you to create test sites for LBI, MBI, and HBI tests. Now we’ll store the values LBI, MBI, and HBI in the sc_BusinessImpact property in each respective site’s property bags.
There are a few ways to do this, but since this is just for testing purposes, I’ll offer two ways to cheat.
Yes, SharePoint Designer 2013 is still around. and it works with Office 365! What’s more, you can use it to easily set custom property bag values using it!
If you haven’t installed it yet, the Chrome SharePoint Editor Extension is a wonderful Chrome Extension that makes it easy to manage property bags. This is how to use it.
It is possible that you run into an issue where SharePoint actively refuses to set the property bag. To resolve this issue, you need to temporarily set DenyAddAndCustomizePages to 0 on each site. To do so:
Launch the SharePoint Online Management Shell.
From the command-line, type:
Connect-SPOService
When prompted for it, enter the URL to your admin site (e.g.: https://mytenant-admin.sharepoint.com) and hit Enter.
You’ll most likely be prompted to log-in. Enter your credentials.
Once connected, type the following, making sure to enter the URL to your LBI site:
Set-SPOSite https://yourtenant.sharepoint.com/sites/testlbi -DenyAddAndCustomizePage 0
Repeat the previous step with your MBI and HBI site URLs, then try again one of the two methods to set your site property bags.
If you wish to do so, you can re-run the above commands setting DenyAddAndCustomizePages to 1 after you’re done setting your property bag values. Thanks to Asish Padhy for the inspiration to set DenyAddAndCustomizePages.
You may think “Bah, I can just go to the SharePoint Admin site, and go to the settings, and enable this”, but as My SharePoint Log pointed out, you’ll have to wait up to 24 hours for this to take effect.
There are plenty of other methods to set property bag values, but the ones I listed above seemed the easiest.
I didn’t spend too much time on how to set up the values because, in a real-world scenario, you shouldn’t be setting the security classification property bag value by hand. It should be automatically configured when the site is created.
That’s something we’ll get to that much later. For now, we’ll focus on changing our hard-coded message bar and make it display the actual site classification.
In the next part of this article, we’ll finally return to code and retrieve the site classification from the property bags and display the appropriate message.