In my last post I described many of the REST endpoints available in SharePoint to manage role assignments. In this post, I will provide a concrete example of using these endpoints in a provisioning-like scenario. I say provision-like because real provisioning scenarios tend to be very specific and one-offs (i.e. I need 7 sites, each with 5 lists and 3 groups, based on a naming convention by organization, and these permissions, and blah and blah and blah). Such specific requirements can’t be written into a one size fits all solution, so I’m just going to mimic them by creating a whole bunch of role assignments, and then deal with some of the issues of initiating a bunch of ajax calls in a short period of time.
REST in SharePoint
Managing Role Assignments/Permissions with SharePoint REST
To assign permissions in SharePoint, you make one or more role assignments, which requires three things:
- Some kind of handle for a securable object. That’s basically a site, list, library, folder, document, or item.
- The principal id for something to which roles can be assigned. That’s either an Active Directory user or security group, or a SharePoint group.
- The id of a role definition. Like ‘Full Control’ or ‘Edit’ or ‘Contribute’. This is basically a named collection of granular permissions that are defined at the site collection root and can be assigned to a securable object in that site collection.
In this post, I’m going to explain the REST service calls required in order to make role assignments to SharePoint securable objects. I will show the calls using jQuery’s ajax (because I’m working through them in the console and the console won’t resolve promises). I’ll follow up with a post with some demo code pulling it all together and probably using fetch.
A Fetch-based CORS Wrapper for SharePoint REST
In this post, I’m going to create a better CORS Wrapper for SharePoint REST operations, and demonstrate using it for CRUD operations on a Picture library. First, I want to remove the dependency of jQuery, using fetch instead. As I covered in a previous post, Ugly SPA Revisited using Fetch and REST, fetch is new enough and implementations are spotty enough, even in evergreen browsers, that I will need to polyfill fetch and ES6 promise in order to support a reasonable cross-section of browsers.
By implementing the full range of CRUD operations on document libraries, we’ll have an opportunity to see if there are other issues that need to be addressed in our CORS Wrapper. My last post really only did one simple REST operation across CORS boundaries.
Determining the Permissions of the Current User with REST
In this post I’m going to show how to determine the current user’s permissions using the SharePoint REST API. This is going to be a little different because I’m just going to run some commands in the JavaScript console, so this is mostly going to be a bunch of screenshots. But since you can’t very well copy and paste from my screenshots, I’ve also included all of the commands I’m going to run in a code block at the bottom of this post.
CRUD Operations for SharePoint Docs Using Fetch and REST
In my last post I talked about the REST service calls of what I said at the time was possibly the ugliest SPA of all time. I wanted to do it with no dependencies, which means interacting with XMLHttpRequest directly, and that isn’t anybody’s idea of pretty. No dependencies also means no promises, and once you’ve programmed with promises for a while, working without them on networking code feels like a step backwards. In this post I’m going to rewrite the ugly SPA with the following changes:
- I’m going to use fetch for all REST calls. fetch is the future, or so they tell me. And it gives me a comfortable promises-based API.
- I’m also going to use “odata=nometadata” for all of my REST calls. As I mentioned in my last post, this may not work in a SharePoint 2013 environment unless Service Pack 1 has been installed and changes have been made to the SharePoint web.config to support JSON light. So if you’re on 2013 and it doesn’t support JSON light, you need to use “odata=verbose” as shown in my previous post.
As I work through the code, I’ll point out differences between “odata=nometadata” and “odata=verbose”. There really aren’t that many differences.
CRUD Operations for SharePoint Docs Using REST
In this post, I’m going to show how to do basic CRUD (Create, Read, Update, and Delete) operations with documents and SharePoint RESTful web services. Along the way, I’m going to flesh out possibly the world’s ugliest SPA (single page application). I’m only going to talk about the parts of the code that deal with Ajax and the RESTful web services, but I’ll attach the complete source. It’s a wiki page, so you can just drop it in a document library and open it to see how it works (it does try to work with a picture library with a title of Pictures in the current site, if you don’t have one, you can either create one or change the listTitle variable to be the title of another picture library in your site).
A Light-weight CORS Wrapper for SharePoint REST
In this post I’m going to demonstrate a CORS Wrapper for postMessage operations, specifically in SharePoint, and intended to make CORS operations as simple as the Ajax operations we’re more familiar with. I’m going to develop the same simple pages I used in my last post, only using the CORS Wrapper this time. Then I’ll dump the CORS Wrapper on you. I’m not going to talk a great deal about the code, I’ve included a ridiculous number of comments in the code to explain what I’m doing.
Anyway, in my last post, I described the basics of using postMessage to do cross-origin web service calls in SharePoint. And I stressed that it is not that complicated. In just under 20 lines of JavaScript, I was able to expose the complete range of web services on a site collection to another site collection. And with another 10 lines of JavaScript I was able to consume one of these web services on another site collection.
And yet, in my experience, a lot of developers think this is too complicated and don’t want to deal with it. I think the reasons for this are twofold:
- SharePoint and it’s web services are already complicated. First, there’s a bunch of them, and they all take different parameters. And you need to set different headers depending on what you’re doing. And is it a GET, or POST, or MERGE. And they’re not very well documented, although that’s getting better. There are plenty of simple examples, but few complex ones (for instance, a lot is left to the imagination when it comes to filters or how lazy loading works).
- While postMessage does not add a ton of complexity, adding any complexity at all makes developers groan in agony (mostly because of reason 1).
Looks like an opportunity for some sort of CORS Wrapper or library. Deal with the complexity once, and forever more use the library to hide most if not all of the additional complexity.
REST Calls Across HNSCs (CORS)
First of all, what is CORS? It stands for Cross-Origin Resource Sharing, and if your eyes have already glazed over a little, don’t worry; it really isn’t that complicated. Say you have a site collection at https://intellipointsolutions.com, and it has some JavaScript that wants to load something from https://source.intellipointsolutions.com. The thing on https://source.intellipointsolutions.com is a cross-origin resource (or CORS), because https://intellipointsolutions.com is an origin and https://source.intellipointsolutions.com is a different origin. Now the origin is just the part of the URL up to the fully qualified host name (and port if a non-standard port is used), so https://intellipointsolutions.com/something and https://intellipointsolutions.com/somethingelse are NOT cross-origin resources, they both have the same origin of https://intellipointsolutions.com.