1 minute read
I get frequent questions about how to elevate permissions when working with the SharePoint Web Services. The answer on this one is really simple: you can’t.This has come up multiple times in the comments on the survey I’m doing about SPServices right now. Yes, right now! Please fill it out if you haven’t already, and help me make SPServices better.Think about this for just a minute. SharePoint’s Web Services allow anyone anywhere to do reads and writes to SharePoint list and libraries. But there’s far more: we can create sites or delete them, create or alter lists and libraries, read or update user profile information, and on and on.
Now think about the security implications of allowing elevated permissions, and you might quickly realize that it’s not such a great idea. If you work for a large company and have a Security Team or an Enterprise Architecture team, or any of the types of teams that look at the software you use with a critical eye, then you know that elevating permissions client-side with script would just scare the dickens out of them. Client-side code may or may not go through the rigorous QA and security checks that your governance dictates — I know that all of your managed code is regularly checked for security issues, right? — so the KISS principle is the right one here.
So, no, you can’t elevate permissions with the Web Services and therefore I can’t provide you that capability with SPServices. You need to manage the permissions as you do for users through the UI and make sure that any user who needs to accomplish something has the permissions to do so. I’m good with that, and you’ll have to be, too.
Oh, and please fill out the survey. Did I mention that?