SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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 am investigating the below code to make sure if its quality is as per Microsoft standards. Actually Comments came from Microsoft code reviewer that we need to create new SPSite Object within the elevated code in delegate. //ExtranetManager is my custom class

I Investigated and have tried to fix but i don't believe that anything wrong with this code. I want to take help from experts in this forum if any body can give good comment about that code or if there is something wrong within elevated privileges. Any comment can help me that may be i am missing.

public class MyTimerJob : SPJobDefinition
        {
           public override void Execute(Guid targetInstanceId)
            {
                SPWebApplication wa = null;

                  wa = (SPWebApplication)base.Parent;
                    SPSecurity.RunWithElevatedPrivileges(delegate
                    {
                        ExtranetManager extranetManager =
                          new ExtranetManager(wa);
                        extranetManager.StartSynchronization();
                    });
               }
        }
share|improve this question
1  
Are you using and SPSite or SPWeb objects inside the ExtranetManager class? if yes, you need to instantiate them afresh. – SlackerAmit Feb 17 at 13:00
up vote 0 down vote accepted

RunWithElevatedPrivileges only works if the current thread is using impersonation, i.e. IIS. Used in other code (timer jobs, console applications, workflow, etc.) it will have no effect. Colin is correct that by default the timer service runs as the farm service account specified in the Configuration Wizard. You can verify this in Windows Services.

Source

share|improve this answer
    
I can't speak for timer jobs or workflow, or technically console applications either but I'm developing a winforms application - which should have basically the same execution context as a console app (the user that starts the application) - and it can't do certain things without a RunWithElevatedPrivileges delegate, and then of course getting a new SPSite in the new elevated context. Do you have a source that shows how that's not necessary? – Code Jockey Feb 17 at 17:46
    
I guess I'll cut and paste my comment to your "source" as well... – Code Jockey Feb 17 at 17:49
    
I'll try and find an authentic source, but have you tested if the RWEP actually works in WinForms, I remember trying to use it in console app which didn't have any effect whatsoever. Had to instantiate new SPSite using SPUserToken of the SystemAccount. What RWEP does is that it creates a new thread with the security context of the user running the Application Pool which in case of WinApp/ConsoleApp would be that of the User running the app effectively having no effect whatsoever. – SlackerAmit Feb 18 at 6:12

The actual point is: there's no need at all to use SPSecurity.RunWithElevatedPrivileges in a job.
A job runs in OWSTIMER.exe, which uses the "SPFarm" account. "SPFarm" account has all privileges against all content DBs; it's seen as "system account" everywhere. So there's really no need to elevate its privileges at all.

However, as a side note, code inside SPSecurity.RunWithElevatedPrivileges must use new fresh SharePoint objects (i.e. new SPSite):

  • A new SPSite must be explicitely open from the elevated section, so its flagged with the elevated identity.
  • All SharePoint objects used inside the elevated section must come from that new SPSite, while it's kept open.
  • This new SPSite must be built and closed from the elevated section.
  • After it's closed, you can't use any of the "child" object anymore.

In the case of your code, and assuming it really needs an elevation context (i.e. let's assume it's not in a job as it actually is): the following code must open and close SPSite objects with respect to previous rules:

ExtranetManager extranetManager = new ExtranetManager(wa);
extranetManager.StartSynchronization();
share|improve this answer
    
Add a because why, and this will be a great answer – Eric Alexander Feb 17 at 13:11
    
Sorry, was about to complete my answer, when I got a call :) I'm back on it! – Evariste Feb 17 at 13:37

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.