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.

Now, to get started, I need to open the browser and navigate to a SharePoint site. Then hit F12 to launch the debugger (or whatever shortcut your browser supports) and tab to the console. I need to be on a SharePoint site already because I’m going to use the global _spPageContextInfo in order to make my commands generic enough to work anywhere and to avoid CORS concerns.

I also need to mention that I have jQuery loaded on every page in this site, so I’m going to use $.ajax to make the network calls. If you don’t have jQuery loaded, you’ll need to get it loaded if you want to follow along. You can do that any way you want, install it as a script link, load it in the master page, or add a content editor web part to your page. If you really don’t want to modify the page or site, you can run the following code in the console, which will load jQuery from a CDN just for this session (although some browsers might block this, works fine in IE).

In my last post I showed using fetch and said I’d probably be using it regularly in the future, so why aren’t I using it now? And also, I said I wanted to use fetch because I’ve grown used to using promises, but I’m not using them either. What gives? The answer to both questions is the same: promises DO NOT resolve in the console, so this would be a short and uninteresting post if I tried to use them.

Anyway, once you’ve navigated to a SharePoint site, opened the console, and made sure jQuery is loaded we’re ready to start.

Get the Current User

So the first thing that we need to do is get the current user’s login name. We can get the current user’s id from _spPageContextInfo, but to get the name we have to talk to the server. We’ll call the REST endpoint ‘/_api/web/currentuser’ like so:

There isn’t that much to say here, but in no particular order:

• There are no inputs to this call, it’s not like I have to tell it which use I want, it’s the current user as the name implies.
• The return is a JSON object with a lot of information about the current user. The only information I need is the user’s login name, so I add $select=LoginName to the request parameters and now I get back a user object with one property, the login name.
• I store the login name in the global my_loginName to use it in my next call.

Get User Effective Permissions

The next thing I need to do is get the user’s effective permissions from the endpoint ‘/_api/web/getusereffectivepermissions’. I pass in the login name I got back from the call to the current user endpoint. Here’s the call:

About this call:

• The login name looks something like: “i:0#.f|membership|somebody@intellipointsolutions.com”. This is a claims identity login name, and it contains special characters that will cause issues in a URL, so it needs to be escaped when sending it in. If you forget this, you’ll get an error message back from SharePoint saying something like “Bad Query: /_api/web/getusereffectivepermissions(‘i:0”. That’s because a hash (#) has special meaning in a URL, it represents a bookmark and it has no business being in the middle of a URL like this.
• The return is a JSON object with two integer properties called High and Low. What are they? Who cares? If you’re doing it right, you’re never going to work with them directly. If that doesn’t satisfy you and you really need to know, the effective permissions are a 64 bit integer, JavaScript is a 32 bit language, so they are the high bytes and low bytes of a 64 bit integer split out into 2 32 bit integers. Feel better? I know I do.
• I assign the resulting JSON object to the global variable my_effectivePermissions, because I’ll need it later.
• Notice that I’m using “application/json;odata=nometatdata”. If I were using verbose, the effective permissions would be burried a little deeeper in request.responseJSON.GetUserEffectivePermissions.

We’re now done with the REST API, in fact we’re done talking to the server. To make sense of the effective permissions we’re actually going to switch over to using the client object model, but only to use a helper class that helps interpret effective permissions. Nothing we do from here on which reach back out to SharePoint.

Initialize SP.BasePermissions Instance

SP.BasePermissions is the helper class I’m going to use to make sense of the effective permissions. It has a handy initPropertiesFromJson method, which takes in the JSON object I just got back from ‘/_api/web/getusereffectivepermissions’.

Convert Permissions it to Friendly Names

Now that I have an SP.BasePermissions instance for the current user, I can call it’s has() passing in an SP.PermissionKind, and it will return true or false depending on whether the base permissions indicates the user has that particular kind of permission.

Do remember that the SP.BasePermissions object is for a particular context. For instance, I called web/getusereffectivepermissions, so my SP.BasePermissions instance tells me about the user’s permissions at the web level. It tells me nothing about what the user can do with respect to a particular list. To find that out I’d call “api/web/lists.getbytitle(‘listTitle’)/getusereffectivepermissions”. Theoretically, there should be a getusereffectivepermissions for every securable object in SharePoint. I can’t say I’ve actually confirmed that.

In the code below, I’ve looped through each permission kind, determined if the user has that permission, and if so added a user friendly string to an array of strings. At which point I can also check if a user has a permission with something like friendlyPermissions.contains(“browseDirectories”) (assuming my browser has Array.contains).

Sum Up

In client-side SharePoint solutions, we often want to tailor the user experience based on what the current user is allowed to do. This is one way to achieve that result using the REST API. Below is all of the commands I issued in the console screenshots above.

One thing that concerned me was can the average user call this even for their own permissions, or does it require “Manage Permissions”. “Manage Permissions” is required in order to call this for another user, but not to call on yourself. I don’t know what the minimum requirements are to call it, but the OOB Visitor Group and Read permission level are sufficient.

Reference

• Securable Object
• SP.BasePermissions