10

I have developed a Cloud App for SharePoint 2013 on an office 365 server, and I figured out that to set the user permissions(who has access to it) for that app can be find over https://sharepoindomain/sites/mysitecollection/MyAppName/_layouts/15/user.aspx

In there I can see and manage the user permissions access and stuff like edit and read and everything exclusively for my app.

So if I see that in there i thought there was a way to get them through the Rest API or JavaScript CSOM so I started looking on https://sharepoindomain/sites/mysitecollection/MyAppName/_api/web and then I found a method named SiteUserInfoList

I accessed to it like this: https://sharepoindomain/sites/mysitecollection/MyAppName/_api/web/SiteUserInfoList/items

And it seems to mee that this was the right area for getting the user permissions for that app but I don't know if I'm correct because when I added a user, and after that I deleted it , it still shows the deleted user on the SiteUserInfoList/items, I noticed that every user has a Property Called Deleted which is boolean but even if its added or deleted, the user still shows when the Deleted Property as False.

So that's why I have double thoughts about this and I don't know if I'm in the wrong way.

I basically want this to show or hide a link in some page over the https://sharepointdomain/sites/mysitecollection/ according to if the current user has permission to properly access to that sharepoint app

is it possible?

Thank you so much for your help

4
+50

The Site User Info list is cached. So yes you can use it, but no it won't be up to date all the time.

You are better off using the User and Groups part of the REST api for this.

MSDN: http://msdn.microsoft.com/en-us/library/office/dn531432.aspx

Direct link to the cheat sheet from MSDN: http://zoom.it/OLUf#full

The correct way is to check if the user has access to the correct group to show the link. The links then show the permissions.

Alternatively if you don't want to use this method you can use

Web/DoesUserHavePermissions

The results can be compared to the enum SP.PermissionKind.

Both ways are valid, groups is the proper way as it is easier to manage.

  • 1
    Groups is definately not something I recommend using if it can be avoided for other than very general permissions that "never" change. All ACL changes on SharePoint groups causes a full reindex in the site! – Anders Rask Feb 5 '14 at 6:51
  • technet.microsoft.com/en-us/library/gg128955.aspx I point you towards the recommendation in 2013 to not avoid groups as this is no longer an issue with continuous crawl – Hugh Wood Feb 5 '14 at 9:24
  • Well this contradicts what Kirk Evans have elaborated on the mechanics behind what happens (in SP2013 also) when you add an ACL to a group in SharePoint. Setting the permission triggers a full crawl blogs.msdn.com/b/kaevans/archive/2013/05/06/… will have to ping him or Neil to hear whats what :) – Anders Rask Feb 5 '14 at 9:49
  • He states "I do not have continuous crawls configured for this environment" which will be the reason he sees this behavior. He may not of known this as it wasn't publishing until this January 2014. – Hugh Wood Feb 5 '14 at 9:52
  • I couldn't test it, I wanted to check it against an AD groupd but appareantly can not be done against an AD group, the Doesuserhavepermissions cold work with JSOM but not with the rest api because the current user may have not access to use the rest api but can have access, but to what specific permission kind should I compare it?? I just need to know if it has access to the page.. so the person doesn't get the access denied exception – Mr. Apr 2 '14 at 23:54
2

You should use CSOM for this. You can use a combination of RoleAssignment and RoleDefinition to assign the proper permissions for the proper users.

function example22() {
    var ctx = new SP.ClientContext.get_current();
    this.oWeb = ctx.get_web();
    this.oUser = oWeb.get_currentUser();
    this.oRoleDef =
    this.oWeb.get_roleDefinitions().getByName(“Restricted read-only access”);
    var roleDefinitionBindingColl =
    SP.RoleDefinitionBindingCollection.newObject(ctx);
    roleDefinitionBindingColl.add(this.oRoleDef);
    var oRoleAssignment = this.oWeb.get_roleAssignments().add(
    this.oUser, roleDefinitionBindingColl);
    ctx.load(this.oUser, “Title”);
    ctx.load(this.oRoleDef, “Name”);
    ctx.executeQueryAsync(
    Function.createDelegate(this, this.onSucceededCallback),
    Function.createDelegate(this, this.onFailedCallback));
    }
    function onSucceededCallback(sender, args) {
    alert(“User ‘” + this.oUser.get_title() + “‘ assigned to role ‘” +
    this.oRoleDef.get_name() + “‘.”);
}

Googling RoleDefinition or RoleDefinitionBindingCollection gives your alot of boilerplate code. The pasted code example was taken from this blog: http://go4idm.blogspot.dk/2011/01/accessing-users-and-roles.html

  • Pst Anders typo on CSOM matey – Hugh Wood Feb 4 '14 at 9:31
  • well edit it then ;) – Anders Rask Feb 4 '14 at 11:55
1

i had to do something similar in a cloud app very recently and used the following code to show and hide a menu which only Admin can see.

context.load(web, 'EffectiveBasePermissions');
context.executeQueryAsync(onQuerySucceeded, onQueryFailed);

function onQuerySucceeded(sender, args) {
    // Success returned from executeQueryAsync
    userName = web.get_currentUser();
    userName.retrieve();


    if (web.get_effectiveBasePermissions().has(SP.PermissionKind.manageWeb)) {
        hideAllPanels();
        $('#adminMenu').fadeIn(500, null);

    }
    else {

        $('#adminMenu').hide();
    }


}
function onQueryFailed(sender, args) {
    // Failure returned from executeQueryAsync
    var divMessage = document.createElement("DIV");
    divMessage.setAttribute("style", "padding:5px;");
    divMessage.appendChild(document.createTextNode("Failed to get started. Error: " + args.get_message()));
    errArea.appendChild(divMessage);
}
  • 2
    I think that hack can be categorized as "security by obscurity" :) – Anders Rask Feb 4 '14 at 11:58
  • Not sure what you mean by this? – Stephen Feb 5 '14 at 9:54
  • 1
    Hiding an element from the user is not the same as disabling that the user can do it. Since the user still has permissions to do this, if he knows the right link, you merely made it a little harder to circumvent. en.wikipedia.org/wiki/Security_through_obscurity – Anders Rask Feb 5 '14 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.