Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Impersonation not working

  Asked By: Stephanie    Date: Oct 25    Category: Sharepoint    Views: 1668

I've written a webpart to permit access to a sharepoint page for
certain site group users. The webpart works for sharepoint
administrative users, but challenges for user id and password for
the user having reader access to the page. With my limited
sharepoint development knowledge I believe that the impersonation
that I've used is not working. Here's the snippet of my code:

protected override void RenderWebPart(HtmlTextWriter output)
oCurrentWeb = SPControl.GetContextWeb(Context);
bool grantAccess = false;
bool siteGroupExist = false;

//RevertToAppPool imp = new RevertToAppPool();
Impersonator imp = new Impersonator();
//loop through the site groups to ascertain site group exists
SPWeb myWeb = SPControl.GetContextWeb(Context);
SPRoleCollection siteRoles = myWeb.Roles;
foreach(SPRole role in siteRoles)
//Check if site group exists
if(role.Name.Trim() == sitegroup.Trim() )
siteGroupExist = true;

// if site group exists then loop through the user roles
if (siteGroupExist)
// Get the user
SPUser myUser = SPControl.GetContextWeb(Context).CurrentUser;
//and user Roles
SPRoleCollection userRoles = myUser.Roles;
foreach(SPRole myRole in userRoles)
if(myRole.Name.Trim() == sitegroup.Trim() )
grantAccess = true;
catch(Exception ex)




9 Answers Found

Answer #1    Answered By: Michelle White     Answered On: Oct 25

It may be this line that is causing you problems:

SPUser myUser = SPControl.GetContextWeb(Context).CurrentUser;

It might be confused about who the current user  is when you are doing a

Another thing you can try is starting at the end and commenting out a
line of code  at a time and see when you stop getting prompted.

Answer #2    Answered By: Sheena Ray     Answered On: Oct 25

Move the line SPUser myUser = SPControl.GetContextWeb(Context).CurrentUser;
before you impersonate

Answer #3    Answered By: Jaime Weaver     Answered On: Oct 25

Here is what I did..

and I didn't have to include any passwords/login names in the code..

Answer #4    Answered By: Damon Garner     Answered On: Oct 25

One of the biggest problems with impersonation  is that you're referencing a
SPWeb object that has already been opened up with the current context  of the
user calling it. You need to open another copy of the web after
impersonating and work from that object.

Answer #5    Answered By: Karla Morrison     Answered On: Oct 25

but there are some things that cannot be done within the
current context. Manipulating Web Roles is one of them. See my
Knowledgebase article:

To overcome these limitations, see my second favorite Maurice Prather
post here:

I discovered this very early on and spent quite a bit of time working
with PSS to discover that this was just not something that we will
easily overcome in this release. I prefer getting a new security context
using a Web Service to using a secondary AppDomain. But I've done both.

My credential-less RevertToAppPool and RevertToSystem methods work
against about 80% of the SharePoint Object Model.

Answer #6    Answered By: Patricia Richardson     Answered On: Oct 25

I have another idea, which is to validate logged-in user  against an
AD group  instead of site  group. Does anyone have a sample code  to

Answer #7    Answered By: Alexandra Patterson     Answered On: Oct 25

I went back because I started having the same problem as Ben did, and found our mutual posts and used his solution to fix my problem.

Answer #8    Answered By: Christop Mcfadden     Answered On: Oct 25

Did you mean you were having impersonation  problem when browsing through SPUser roles. If so, what was your solution?

Answer #9    Answered By: Stefanie Ruiz     Answered On: Oct 25

It wasn't roles  specifically, what I'm working  on is a project to display reports to users. These reports are stored in several different document libraries, and the users  have absolutely no access  to them due to the confidentiality of the reports. They only see a tree view of the folder structure, and the reports they are authorized to see. When they click on a report, I am impersonating and then reading the file and streaming it back to them for display.

Here's the snippet of code  (using Todd's great Impersonation routine).


// do your security restricted code here


The part in orange is what I needed to add, because of the issue discussed in the Blue Dog post about the way Sharepoint handles authentication in the context  of an IIS response.

Didn't find what you were looking for? Find more on Impersonation not working Or get search suggestion and latest updates.