1

Say I have a custom web part that queries a list or adds list items, etc. Does the user have to have the equivalent permissions on the list itself to use the web part? Would the SPSecurity.RunWithElevatedPrivileges Method be a way to get around this? Or is there a better way?

Basically I want certain users to have a more controlled access to a list. But if I try to access the page with the web part on an account without permissions for the list, I get an Access Denied response.

1

One way of elevating code is, as you already mentioned, using SPSecurity.RunWithElevatedPrivileges which will run SPSecurity.CodeToRunElevated with Full Control rights. From MSDN documentation of the method for SP 2013 (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx) you can see that this code runs under Application Pool identity:

Type: Microsoft.SharePoint.SPSecurity.CodeToRunElevated

A delegate method that is to run with elevated rights. This method runs under the Application Pool identity, which has site collection administrator privileges on all site collections hosted by that application pool.

Another method, a bit more security fine-grained, can be used. The idea is to instantiate new SPSite object using overloaded constructor which takes Microsoft.SharePoint.SPUserToken as a parameter: http://msdn.microsoft.com/EN-US/library/ms469253(v=office.15).aspx. Example can be seen here: http://www.sharepointdeveloperhq.com/2009/04/how-to-programmatically-impersonate-users-in-sharepoint/. Using this approach, you can run your code in the context of the user who doesn't necessarily have to be site collection admin. This user can have only access to the list in question.

0

Yes in those cases you should elevate the code, do the operation. There is no other way around this.

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.