I'm working in code to elevate an account with the Read role to a specific account with the Contribute role in order to create a list item.

I currently get the SPUserToken for the contribution account by reading


and I was suprised to note that this works as long as you have the Read role on the web. (This means I don't need to open the web in a RunWithElevatedPrivileges block just to get the token - brilliant!)

However, if alternatively I try to use


then I am denied access - because the Read role doesn't have the Enumerate Permissions permission. Microsoft have explicitly checked for that permission before returning the token.

I am rather worried by the fact that Microsoft have seen fit to block off one way of getting the token, but not the other. The documentation for GetUserToken does say it checks permissions, but I'd expect any other method of getting the token to make such a check too.

Can anyone tell me if there's a good reason for this difference?

  • Coherence? Since the rest of it is bugged, why should this follow common sense? Just joking... anyway, good point in finding this, +1 for the question. Now we only need someone to find an answer. If I should make a bet, I would say that they use the first method somewhere in the code in a context where the check isn't appropriate or could lead to problem, so that in the end they had to live with it.
    – SPArcheon
    Mar 12 '13 at 14:31

Do you really need to impersonate a different user? Or just temporarily need permission to write to a resource?

These scenarios are covered here: http://www.schaeflein.net/impersonation-and-elevation-of-privilege/

  • I'm doing this in order to create a list item in a list which the user can see but not contribute to. I want to use an account that is specifically for creating these items, not elevate to the all-powerful site collection admin account.
    – Rawling
    Mar 13 '13 at 11:48
  • Then you need to get that account token while that user is logged on. Or you need to know that account's credentials. Or you have to use the SystemAccount (which is the recommendation). Mar 13 '13 at 15:10
  • Nope. I've successfully got the token without the user being logged on, without knowing the credentials, and without escalating to the system account. I can do this by calling web.Users[x].UserToken on a web on which I have Read permissions, as I've said in the question.
    – Rawling
    Mar 13 '13 at 15:27
  • I would suggest that since it does not work in all scenarios, you do not successfully have the token. The approach documented in my article has been validated by the product group and is in use in countless farms. Mar 14 '13 at 22:07
  • In that case, something even worse is going on, because Sharepoint is letting a user with Read permissions create list items without even successfully having the token.
    – Rawling
    Mar 15 '13 at 8:20

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.