SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been pulling my hair out long enough on this one.. would appreciate some help :)

I've created a custom DataFormWebPart which I need to render certain contents to all users of a sharepoint list. We wanted it to render using the SPSecurity.RunWithElevatedPriviledges delegate because the list is locked down to only a few users.

I've tried to override the DataFromWebParts Render(),RenderContents() methods using the SPSecurity.RunWithElevatedPriviledges delegate however it's not rendering the content under the elevated permissions. Users are still unable to view the data because they don't have access...

share|improve this question
up vote 3 down vote accepted

It sounds like the context is opened as the current user. You need to run RunWithElevatedPermissions before the data is queried from the current context. So if you are using SPContext.Current, don't. Open a new SPSite and SPWeb within your RunWithElevatedPermissions delegate.

share|improve this answer
Guess I'm still not clear where I implement this logic. Would it be during the OnLoad event? Or do I override a property on the dataview web part? – RobB Apr 14 '11 at 13:51

By the time it hits Render(), it has already fetched the security trimmed data. You need to RunWithElevatedPriviledges at the point it fetches the data.

share|improve this answer
I agree, but at what point exactly does it do it's security trimming? – RobB Apr 14 '11 at 0:50
If it behaves like most other aspects of SharePoint that is when it displays data, I believe Search results work like that. It grabs all the data on connect but on display it's trimmed. That's been my understanding anyway... – MichaelF Apr 14 '11 at 12:25

A small word of caution is that you are trying to elevate in normal HTTP GET requests. Effectively for every request to a page that contains this web part you will double the amount of database interaction since as Jason mentions, you need to retrieve new SPSite and SPWeb objects. The SPWeb holds on to the 'CurrentUser' so you need to renew them. This is quite expensive.

share|improve this answer

The obvious answer to me is then to open it up to everyone at the read level and give the select few people the ability to edit the list content. Navigation to the list can always be hidden in various ways so it isn't easily accessible to the masses but still made easily editable by those that need to.

share|improve this answer
This solution was proposed prior to my involvement. We didn't want to give everyone read access to this information. It contains HR related data. We just wanted to expose a few fields using a DataFormWebpart along with using a CurrentUserWebPart. It sounds like your proposing security through obscurity which hasn't worked for us in the past. – RobB Apr 14 '11 at 16:04
Yes, with audience targetting on the list web parts and setting default filtered views that display on the current users data, you can solve most of that. I prefer to use code as the last resort and I don't feel code is necessary in this situation. – Eric Alexander Apr 14 '11 at 16:32

Your Answer


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.