SharePoint 2007 - RunWithElevatedPrivileges - Fehler bei der Verwendung dieses

Gründe, den Fall in zwei Kategorien zu heben:

1. Ihr Code muss Vorgänge in SharePoint ausführen, für die der aktuelle Benutzer keine Berechtigungen hat. Dies sollte immer während der Arbeit mit SharePoint-Sicherheit erfolgen, nicht als "nur für den Fall" -Maß, der anzeigt, dass Sie Ihre Sicherheitslage besser verstehen müssen.
2. Ihr Code muss auf externe Ressourcen zugreifen (Serverdateisystem, Datenbank, Dateifreigabe usw.), auf die die Anwendungspoolidentität Zugriff hat, der aktuelle Benutzer jedoch nicht.

Für Ersteres ist es viel besser, den SPSite-Identitätswechsel zu verwenden. Letzteres ist der einzige Grund, warum ich RWEP benutze.

Um zu verdeutlichen, erzeugt RWEP keinen neuen Thread. Stattdessen verwendet es Win32-APIs, um die Identität des aktuellen Threads zurück in die Prozessidentität (Deaktivieren des Identitätswechsels) zu versetzen, um den erhöhten Code auszuführen, und anschließend den Identitätswechsel wieder einzuschalten, um die Arbeit für den aktuellen Benutzer fortzusetzen. Dies hat mehrere Auswirkungen:

1. RWEP tut nichts, wenn der Thread nicht imitiert wird. Daher ist es bei Timer-Jobs, Visual Studio-Workflows, Konsolenanwendungen und Code, die über stsadm (Feature-Empfänger) ausgeführt werden, nutzlos.
2. Der Zugriff auf SharePoint, vorausgesetzt Sie erstellen eine neue SPSite in Ihrem CodeToRunElevated, wird mit den Rechten des Anwendungspools ausgeführt (SHAREPOINT \ system). Dieses Konto hat vollen Zugriff auf die aktuelle Webanwendung, aber sollte keine Berechtigung auf Farmebene haben, um beispielsweise SPFarm-Eigenschaften zu ändern oder Änderungen am SSP vorzunehmen.
3. Die Verwendung identitätsbewusster Objekte (wie SPSite und seine Kinder) über die Ausführungsgrenzen hinweg von CodeToRunElevated hat das Potenzial, einige wirklich unkonventionelle Verhaltens- und Rennbedingungen zu verursachen. Für alle Absichten und Zwecke, betrachten Sie dies nicht unterstützt.

Und wie Alex schon gesagt hat, erben die Kinder einer SPSite ihre Berechtigungen von der SPSite, die wiederum ihre Berechtigungen bei der Erstellung hat. Daher verhält sich SPContext.Current.Site immer noch mit den Berechtigungen des aktuellen Benutzers, selbst wenn Sie in Ihrem CodeToRunElevated darauf verweisen. Stattdessen müssten Sie eine neue SPSite innerhalb des erhöhten Blocks erstellen und konsumieren.

Um es zusammenzufassen: RWEP, um den App-Pool außerhalb von SharePoint zu verfälschen, SPSite-Identitätswechsel, um die Identität des App-Pools in SharePoint anzunehmen.

1) Eine substantielle Verwendung von RWEP ist ein guter Hinweis auf Code-Gerüche. Es kann leicht ohne Gedanken missbraucht werden, was zu ernsthaften Sicherheitsproblemen führt. Viele Entwickler denken nicht darüber nach, was Benutzer mit der Macht tun könnten, die ihnen indirekt "unter die Haube" gegeben wird.

Nur ein Beispiel: Es ist wichtig, ValidateFormDigest aufzurufen, bevor Sie RBEP verwenden, um bösartige Anfragen in Anwendungsseiten zu verhindern .

2) SPWeb- und SPSite-Objekte müssen im Kontext von RWEP erstellt werden. Dies ist für Anfänger leicht zu vergessen und führt zu vielen Frustrationen.

Diese Einschränkung bedeutet auch, dass alle Arbeiten und alle Objekte, die von diesen Objekten erstellt wurden, vor dem Ende des RWEP-Delegaten verwendet und beendet werden müssen. Dies ist ein weiterer häufiger Fehler.

Keith Dahlby hat Erweiterungsmethoden geschrieben, um diese Probleme zu umgehen lesbarer Code.

RWEP hat wie alles andere Vor- und Nachteile.

Wenn Sie Bedenken haben, dass Endbenutzer RWEP ausführen, haben Sie wahrscheinlich bereits ein größeres Problem, da dieser Code bereits auf GAC installiert wurde.

Manchmal müssen Sie einfach dabei bleiben: Betrachten Sie einen Benutzer, der keine Administratorrechte hat und einen Dokumenten-Workflow ausführt. Nachdem dieser Benutzer ihn genehmigt (oder abgelehnt hat), sollte Ihre Workflow-Engine diese SPListItem-Berechtigungen neu definieren können.

Ich benutze es und finde es sehr nützlich. Meiner Ansicht nach möchte ich, dass der Benutzer meinen Code ausführt und dass der Code Dinge tut, die der Benutzer normalerweise nicht tun kann. Sie können etwas absperren und den Benutzer trotzdem sehr kontrolliert darauf zugreifen lassen.