Frage

Ich habe einen benutzerdefinierten Webdienst, der in SharePoint 2007 sowie SharePoint 2010 ausgeführt wird. Ich teste derzeit nur in SharePoint 2010 in meiner Entwicklerumgebung. Ich habe einen Code, der Folgendes macht:

bool allowUnsafeUpdates = web.AllowUnsafeUpdates;
try
{
    web.Properties[webPropertyBagKey] = value;
    web.AllowUnsafeUpdates = true;
    try
    {
        web.Properties.Update();
    }
    catch (Exception ex)
    {
        // Update failed likely due to security reasons, try with elevated privileges
        SPSecurity.RunWithElevatedPrivileges(delegate()
        {
            using (SPSite elevatedSite = new SPSite(web.Site.ID))
            {
                using (SPWeb elevatedWeb = elevatedSite.OpenWeb(web.ID))
                {
                    bool elevatedAllowUnsafeUpdates = elevatedWeb.AllowUnsafeUpdates;
                    try
                    {
                        elevatedWeb.Properties[webPropertyBagKey] = value;
                        elevatedWeb.AllowUnsafeUpdates = true;
                        elevatedWeb.Properties.Update();
                    }
                    finally
                    {
                        elevatedWeb.AllowUnsafeUpdates = elevatedAllowUnsafeUpdates;
                    }
                }
            }
        });
    }
}
catch (Exception ex)
{
    // log exception, but don't bubble it up...
}
finally
{
    web.AllowUnsafeUpdates = allowUnsafeUpdates;
}

Bevor ich zum obigen Code komme, wurde das SPWEB -Objekt (Web) mit einer Technik geöffnet, um den Site -Eigentümer auszugeben, indem das Benutzer -Token des Site -Eigentümers ermittelt und das Sp -Site -Objekt instanziiert wird, indem das Benutzer -Token bereitgestellt und das SPWEB von dort ausgeliefert wird. SharePoint -API -Anrufe haben also bereits ziemlich erhöhte Privilegien.

Was ich gefunden habe ist, dass mein erstes Web.Properties.update () gut funktioniert, wenn ich mich mit einem Site -Eigentümer mit dem Webdienst authentifiziere. Wenn ich mich jedoch mithilfe eines Benutzers mit dem Webdienst authentifiziere, der lediglich auf das Web zugreifen kann, schlägt mein call web.properties.update () fehl. Nicht schlecht, hatte ich gehofft, weil ich einfach mit erhöhten Privilegien laufen kann (was einen Umkehrungsteiler ausführt und als Besitzer des Bewerbungspools läuft). Dieser Code funktioniert ordnungsgemäß, aber kurz nachdem der Code ausgeführt wird. Der Thread bearbeitet einige andere Anweisungen (z.

Die gute Nachricht ist, dass ich, wenn ich gerade immer zu jeder Zeit raufe, in Ordnung zu sein scheint. Im Grunde genommen macht es ein anhaltendes Problem, den ursprünglichen Versuch zu erfassen, obwohl ich nichts in die Luft sprudle.

Irgendeine Idee, was hier los ist? Ich bin besorgt, dass es andere Orte gibt, an denen ich darauf stoßen könnte, außer nur Spweb.Properties zu sparen.

War es hilfreich?

Lösung

Möglicherweise möchten Sie versuchen, die in der Handhabung von AccessDeniedied -Ausnahmen integrierte SharePoint auszuschalten, die standardmäßig die aktuelle Anfrage absagen und häufig Threadabortexzepte verursachen.

SpSecurity.catchAccessdeniedexception

Wenn Sie diese Eigenschaft auf False einstellen, können Sie die AccessDeniedied -Ausnahme selbst behandeln. Denken Sie daran, den Wert wiederherzustellen, sobald Sie fertig sind.

Andere Tipps

Ich bin auf eine ähnliche Situation gestoßen - zumindest denke ich, dass es das sein könnte. Der Weg, es zu lösen, bestand darin, zu verstehen, was ich wirklich tue, wenn ich zum Beispiel rufeusing (SPSite elevatedSite = new SPSite(web.Site.ID))von in einem Delegierten in RunwitheLevatedPrivilegers.

Die Sache ist, es scheint, dass der Delegierte auf einem anderen Thread läuft. Anstatt Web.site.id (in einem anderen Thread) zu verwenden, müssen Sie alle Daten speichern, die Sie (alle IDs usw.) in einfachen Variablen benötigen, bevor Sie den Delegierten eingeben. Das sollte sich um die Abbrüche von Threads kümmern.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit sharepoint.stackexchange
scroll top