Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

web.Users[actName].UserToken

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

web.GetUserToken(actName)

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?

share|improve this question
    
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. –  SPArchaeologist Mar 12 '13 at 14:31
add comment

1 Answer 1

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/Pages/Impersonation-and-Elevation-of-Privilege.aspx

share|improve this answer
    
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). –  Paul Schaeflein 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. –  Paul Schaeflein 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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.