13

You should recreate context. SPSecurity.RunWithElevatedPrivileges(delegate() { using(SPSite site = new SPSite(properties.SiteId)) { using(SPWeb web = site.OpenWeb(properties.Web.ID)) { //code } } });


12

It depends on what you need to do. RunWithElevated only runs as the Application Pool Identity, so you might not have access to other web applications, only other site collections in the current web application, but you can be guaranteed that you will be running as a user that exists (the AppPool identity). With UserToken, you need to be sure that the user ...


7

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 ...


6

Elevated privileges is not enough to write to the configuration database. With elevated privileges you will use the the web application app pool’s identitty, which has only read permission to the config db by default. Of course admin user (which runs the central admin should have read and write permissions). See more at: http://joelblogs.co.uk/2010/...


5

All permissions required to correct this error: Site Collection administrator on the SPSite (whether given through Central Admin or Site Settings) PowerShell scripting admin: add-spshelladmin domain\username PowerShell scripting admin on the content databases: get-spcontentdatabase | add-spshelladmin domain\username note that the powershell commands must ...


5

Sorry, but there is no way to run at elevated privileges from the client-side, and if there was a way, it would be roughly 0% secure. Depending on what you're trying to achieve, there are some ways that you might be able to work around it. For instance, if you can do it from a workflow, SharePoint 2010 workflows can do an impersonation step which runs as ...


4

Well, SPSecurity.RunWithElevatedPrivileges should do the trick. Make sure, you create a new SPSite/SPWeb within the elevated code block: var siteId = SPContext.Current.Site.ID; SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite site = new SPSite(siteId)) { //do things on the new site object } });


4

RWEP is not available in the sandbox. Your alternative would be to grant a custom permission to the location where you are moving files to that grants the user Add Items or create a full trust proxy. For permissions, in your event receiver, you move the file normally. Users cannot modify items, users cannot delete items, only add new files. Fills the gap ...


4

Try to delete the current httpcontext before elevating (but do not forget to remember it and set it back like var storedContext = HttpContext.Current; HttpContext.Current = null; <Do something> HttpContext.Current = storedContext; Because it seems to use still your curentUsers Credentials when calling the search service (which it still does in the ...


3

I'm not entirely certain this will work, but you could try inspecting HttpContext.User.Identity within the RunWithElevatedPrivileges delegate, and see if it returns the application pool identity. If so, you could provide some way of retrieving the application pool identity for a given SPWebApplication (possibly via SPWebApplication.ApplicationPool?), and ...


3

Hosting.HostingEnvironment.Impersonate is the ASP.NET equivalent to SPSecurity.RunWithElevatedPrivileges. SPSecurity.RunWithElevatedPrivileges cannot work in ASP.NET context as it calls for SharePoint APIs. Source I have an asp.net web app that must execute code under the context of the current user (via identity impersonate, as it needs to call out to ...


3

Please check MSDN: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges(v=office.14).aspx Executes the specified method with Full Control rights even if the user does not otherwise have Full Control. Parameters secureCode Type: Microsoft.SharePoint.SPSecurity.CodeToRunElevated A delegate method that is to run ...


3

The code is correct and is fine! when accessing aspx pages on the server its not running under app pool account its running under nt authenticated account which should be your own! how do i know? i use aspx on layouts page all the time and giving/dening app pool account access would not effect it! a good expample would be two users.. one site collection ...


3

1 should always run under the farm account. For 2, 3, 4, and 5, you should be able to ferret this information out by using this code: SPUser user = SPContext.Current.Web.CurrentUser; string userName = user.Name; //you can also call user.Email here Note that this will not work correctly if you have a 'RunWithElevatedPrivileges' delegate block. Rather, if ...


3

EnableThrottling seems to require Farm Administrator privileges. Take a look at the following code: public bool EnableThrottling { get { ... } set { bool nothrottlevalue = !value; this.SetListNoThrottle(nothrottlevalue); } } internal void SetListNoThrottle(bool nothrottlevalue) { SPSite site = this.ParentWeb.Site; ...


3

From my experience In most cases use SPUserToken (it is safer, ie more secure option), you need to use RWEP only (at least to my knowledge) if you need to have access to file system (ie. saving info to log file would be a good example).


3

If users don't have access to the file, they don't have access to the file, no matter what. So, if you display real links to the file, as far as SharePoint is concerned, they cannot get the files content; when they click the link, they get an "access denied" message. Your only option here is to build an applicative (_layouts) page; that page would take ...


3

Allowing the workflow to run on elevated privileges (enable it to use app permissions), doesn't pose any security holes in SharePoint. Following are the points you should know before using the App step in workflow: The one drawback of using an Impersonation Step is that the workflow could suddenly stop working if anything were to happen to the user account ...


2

We have touched on this subject several times before. Last time i linked to Keth Dalbys explanation on SO https://stackoverflow.com/questions/1525953/sharepoint-2007-runwithelevatedprivileges-pitfalls-of-using-this Which explains why you sould not use RWEP but in very specific situations, like when fetching data outside of SharePoint.


2

This is finally the solution I came to: public static bool IsPrivilegedMode() { using (WindowsIdentity identity = WindowsIdentity.GetCurrent()) { return identity != null && GetProcessIdentity().User == identity.User; } } private const uint processToken = 0x0008; public static WindowsIdentity GetProcessIdentity() { IntPtr handle = IntPtr....


2

The easy thing and which is working 100% is to get CurrentUser from a SPWeb object and compare it against 'SHAREPOINT/SYSTEM'. 100% agree there are cases when is needed to detect if code is already running under elevated privs. Cuz you might have classes calling other methods from other classes and so on and you can't elevate 2 or more times a context. ...


2

Please ensure you use SPSecurity.RunWithElevatedPrivileges in correct way. Consider below points for the same: RunWithElevatedPrivileges does not work when HTTPContext is null. RunWithElevatedPrivileges does not work for a Sandbox Solution. Elevation of privilege occurs only if new SPSite created inside the block. Below is commonly used WRONG way and you ...


2

you should open new context SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite site = new SPSite(SPContext.current.Site.ID) { using (SPWeb web = site.OpenWeb(SPContext.current.Web.ID)) { SPList list = web.Lists["Some List"]; ..... item.update();**// this line works** list.update(...


2

I guess the implementation of XDocument.Load(string) doesn't support an authenticated request to retrieve the XML file. However, there is another way because the approach that you are taking will mean that each time a document is opened two web requests are being made. One to build the Url using the SPFile object To access the SPFile object using the Url ...


2

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/


2

You have two possible situations here. Case A: you are outside the RunWithElevatedPrivileges scope you may be getting an elevated SPWeb instance that has been saved OUTSIDE the scope of the RunWithElevatedPrivileges delegate. This is a code horror in most cases, but it is still possible. In this case, recreating a new instance based on the url of the ...


2

One approach you could try, is enabling content approval on that list. This will mean, that whenever a new item is created, it will remain in Pending status until it is approved. When an item is in Pending status, only the originator of the item and the people who have permissions to manage lists and libraries can see it, provided you chose the following ...


2

You have to know the website that contains AdminList. Here are two ways to go: Create AdminList in the root web of the site collection and then in your code get the webID of the root web Guid webID = SPContext.Current.Site.RootWeb.ID; Guid siteID = SPContext.Current.Site.ID; SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite site = new ...


2

In the end I got around this issue by assigning temporary values to the required fields, updating the item, checking it in, then running the above piece of code with the addition of a check out before calling thisitem.update(), then assigning the required fields back to null. Not ideal but it works.


Only top voted, non community-wiki answers of a minimum length are eligible