[via Daniel Larson]
Daniel Larson, a MOSS MVP, has been ranting over the past few days about the use of the SPSecurity.RunWithElevatedPrivileges method. While I have been amused with his rants, I share his concerns and frustrations as a result of using the method in my SharePoint development experience and seeing the method abused and missused in many code reviews. Today, he posted a list of his best practices for gaining “elevated privileges” SharePoint.
Daniel Larson’s list of best practives for elevated privileges in SharePoint:
- Avoid using SPSecurity.RunwithElevatedPrivilege to access the SharePoint object model. Instead, use the SPUserToken to impersonate with SPSite.
- If you do use SPSecurity.RunwithElevatedPrivilege, dispose of all objects in the delegate. Do not pass SharePoint objects out of the RunwithElevatedPrivilege method.
- Only use SPSecurity.RunwithElevatedPrivilege to make network calls under the application pool identity. Don’t use it for elevation of privilege of SharePoint objects.
- Always use the SPSite constructor with an SPUserToken to create an elevated privilege security context in SharePoint. To impersonate the system, use the SystemAccount.UserToken property of the current SPSite context, such as:
var site = new SPSite(SPContext.Current.Site.ID, SPContext.Current.Site.SystemAccount.UserToken);
- Avoid passing SharePoint objects between different security contexts (SPSite instances), with the exception of the SPUserToken used in the SPSite ctor. An SPUser object created from SPSite A cannot (reliably) be passed to SPSite B. This can be the source of obscure bugs in production that are difficult to reproduce in development. For example, an SPUser reference created from SPContext.Current.Site cannot reliably be used in an elevated site context, as the user reference may take on a different meaning in the alternate context.
- Never use elevated privilege to bypass security– always use it to work with security.
- Restrict what assemblies can use elevated privilege by running in minimal trust, avoiding the GAC, and auditing any CAS policies deployed with vendor solutions.
Two conferences were announced last week that I want to share with you:
PDC2008 [via Andrew Connell] – Regristration for the Microsoft Professional Developers Conference 2008 is now open and is scheduled to take place in Los Angeles on October 27-30 at the Los Angeles Convention Center.
SharePoint Best Practices and Governance Conference [via Bill English] – The conference has been announced and will be taking place in Washington DC on September 15-17.
I would like to attend both of these, but I am not sure if I will be able to.
Robert Bogue raises some challenging questions and makes some powerful statements in his post, How Best are Your Best Practices, regarding his experiences and struggles with reaching consensus on what a best practice is and applying it. I was in the middle of posting a comment to his post when I realized my thoughts on the post were quite a bit more than a couple of lines in a comment box. And without further adeu, here are my thoughts…
Doing what we know we should do
In his post, Robert asks, “when are we going to do what we say?” This question was in context of his findings that there are very few professionals out there that actually use the best practices they know. From a consulting professional perspective, I feel that failing to do what we know we should do is ethically wrong. Clients and customers pay for our expertise and deserve to get it. While I agree that the SharePoint space is so large that even experienced professionals are learning something new about SharePoint on a daily basis, we need to ensure that make use of the best practices that we do know in every project that we undergo regardless of its size and complexity. This is our duty as professionals.
On defining best practices
I agree with Robert when he states that the definition of best practices has been a problem space in software development that has yet to be resolved. There are many reasons for this. But let me list a couple:
- Academically, software engineering methodologies regarding the definition of development practices are still in their infancy. While a lot of progress has been made in this area in the last few decades, software development is not a hard science. Some of us consider it more of an art than a science.
- While progress has been made academically in this problem space, there is a large disconnect between academic approaches to the problem and practical approaches used in the industry. I think some of this has to do with the cost of trying different frameworks that generate process and procedures that still end in leading a good number IT and software projects to failure.
So what can we do to help reach consensus on best practices? Honestly, I don’t have a good answer to this question right now. What I can tell you is that what ever practice we do try to use, whether a best practice or not, we should make the effort to take review how the practice helped or hindered us, learn from the experience, and share it so that we may continue to define new best practices and debunk those practices that are not so best anymore (assuming they really were a best practice at one time).