Skip to main content

Cloud

SharePoint 2010 Permissions and RunWithElevatedPrivileges Context

These days, many people are using SharePoint anonymously or creating mash-ups of data from various SharePoint sources.  As a result, these various resources have differing permissions governing their visibility.  For example, the Managed Metadata Term Store cannot be accessed anonymously. 

Indeed, the most likely occurrence, and where I discovered this problem, is when you want to display all items in a list even if the current user doesn’t have permissions to edit or view the item.  My specific situation was for an editor that needs to know a particular topic exists but doesn’t have the permission to see or edit the topic.

Displaying content from a secure source on a site must be done after the user has logged in or (more likely) via SPSecurity.RunWithElevatedPrivileges.  This was the only solution in my case.

Once inside the RunWithElevatedPrivileges security delegate, it’s well known that you must recreate any object that you need to access with full permissions.  This is because previously created objects maintain their security context once inside the security delegate.  So an SPSite created outside of the delegate will have the same permissions as it does inside the delegate.  Although not necessarily straightforward, it’s intuitive that permissions would not get remapped within the delegate.

Slightly less intuitive, and poorly documented, is the fact that the security context for objects created within the security delegate is maintained once you leave the delegate.  So if you get a reference to an SPListItem within the security delegate and pass it outside of the delegate, you will still have full control on the item because it was referenced from within the security delegate!

This behavior can lead to some interesting ramifications.  In my case, the use of the DoesUserHavePermissions method on the SPListItem class was acting strangely.  Calling this method on the item I got out of a security delegate always returned true because the security context followed the object.  To avoid this unfortunate situation, I had to get a reference to the item outside of the security delegate to get the correct permissions for the object.

In general, treat SPSecurity.RunWithElevatedPrivileges as a separate context entirely and don’t reuse objects across the context boundary for items with permissions.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Andrew Schwenker

Andrew Schwenker is a Sr. Technical Consultant within Perficient’s Microsoft National Business Unit East's SharePoint practice. Andrew has nearly 2 years of experience in consulting and has participated in projects that have touched nearly every aspect of SharePoint 2010. Andrew earned his Bachelor’s degree in Computer Science as well as Master’s degrees in Computer Science and Information Systems from Indiana University. He’s interested in creating winning solutions to generate business innovation using SharePoint. Prior to starting at Perficient, Andrew completed internships with General Electric, ExactTarget, and Great American Financial Resources. During his studies, he actively participated in Alpha Phi Omega National Service Fraternity and competed in the first annual Cluster Challenge at SC07 in Reno, NV. Andrew was a part of the dynamic PointBridge team that was acquired by Perficient.

More from this Author

Follow Us