Einschränkungen bei Sandkastenlösungen
In diesem Thema werden die Einschränkungen für Code beschrieben, der in Lösungen mit eingeschränkter Sicherheitsstufe ausgeführt wird.
Letzte Änderung: Mittwoch, 13. April 2011
Gilt für: SharePoint Foundation 2010
Inhalt dieses Artikels
Dreifacharbeitsprozesse
Sicherheitstoken mit niedrigen Rechten für den Sandkastenarbeitsprozess
Restriktive Richtlinie für die Codezugriffssicherheit für den Sandkastenarbeitsprozess
Spezielle Versionen der Microsoft.SharePoint.dll-Assembly
Getrenntes Seitenrenderingsystem
Einschränkungen beim Ressourceneinsatz
Farmbezogene Validierung von Lösungen
Farmbezogene Blockierung von Lösungen
Farmbezogene Blockierung von Klassen
Verschiedene Einschränkungen
Verfügbar in SharePoint Online
Die verschiedenen Einschränkungen können basierend auf den Mechanismen, die den Einschränkungen zugrunde liegen, sinnvoll in die folgenden Kategorien aufgeteilt werden.
Dreifacharbeitsprozesse
Sicherheitstoken mit niedrigen Rechten für den Sandkastenarbeitsprozess
Restriktive Richtlinie für die Codezugriffssicherheit für den Sandkastenarbeitsprozess
Spezielle Versionen der Microsoft.SharePoint.dll-Assembly
Getrenntes Seitenrenderingsystem
Einschränkungen beim Ressourceneinsatz
Farmbezogene Validierung von Lösungen
Farmbezogene Blockierung von Lösungen
Farmbezogene Blockierung von Klassen
Verschiedene Einschränkungen
Dreifacharbeitsprozesse
Sandkastencode wird wie in Architektur von Sandkastenlösungen erläutert in einem separaten Arbeitsprozess vom standardmäßigen Microsoft ASP.NET-Arbeitsprozess ausgeführt und führt Aufrufe eines dritten, voll vertrauenswürdigen Proxyprozesses aus. Dies bedeutet Einschränkungen für Lösungen mit eingeschränkter Sicherheitsstufe, und zwar unabhängig von den Berechtigungen des Sandkastenarbeitsprozesses.
Einschränkung |
Auswirkungen und Hinweise |
---|---|
Vom WebResources.axd-Handler, der im ASP.NET-Arbeitsprozess ausgeführt wird, kann nicht auf Ressourcen zugegriffen werden, die in den Sandkastenarbeitsprozess eingebettet sind. |
Von Assemblys in Lösungen mit eingeschränkter Sicherheitsstufe können keine eingebetteten Ressourcen verwendet werden. |
Sicherheitstoken mit niedrigen Rechten für den Sandkastenarbeitsprozess
Der Sandkastenarbeitsprozess erhält ein Sicherheitstoken mit niedrigen Rechten. (Dies ist nicht mit dem Benutzersicherheitstoken identisch.) Das Token bewirkt die folgenden Einschränkungen.
Einschränkung |
Auswirkungen und Hinweise |
---|---|
Mit dem Code des Prozesses kann das Dateisystem weder gelesen noch in dieses geschrieben werden (außer dass Assemblys im globalen Assemblycache gelesen und ausgeführt werden können). |
1. Anwendungsseiten, mobile Seiten und Benutzersteuerelemente (ASCX-Dateien) können nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. Dies gilt auch für visuelle Webparts, da sie ein Benutzersteuerelement enthalten. Stellvertretungs-Steuerelemente, die als Benutzersteuerelemente implementiert werden, sind in einer Lösung mit eingeschränkter Sicherheitsstufe ebenfalls nicht möglich. Bestimmte andere Dateitypen können jedoch in der Inhaltsdatenbank bereitgestellt werden und auf diese Weise in Lösungen mit eingeschränkter Sicherheitsstufe eingeschlossen werden. Hierzu zählen Skriptdateien, Bilddateien und Assemblys. (Weitere Informationen finden Sie unter How to: Create and Deploy a non-RESX Resources in a Sandboxed Solution und Wo werden Assemblys in Sandkastenlösungen bereitgestellt?)
Hinweis
Bei den Erweiterungen für die Microsoft Visual Studio Gallery gibt es eine Erweiterung, mit der Sie einem Lösung mit eingeschränkter Sicherheitsstufesprojekt ein visuelles Webpart hinzufügen können. Dies ermöglicht die Verwendung des visuellen Designers, aber das Benutzersteuerelement (ASCX-Datei) wird zusammen mit dem zugrunde liegenden Code in die Assembly kompiliert. Es wird nicht mit der Lösung bereitgestellt. Daher stehen die Vorteile der ASCX-Bereitstellung durch durch diese Erweiterung nicht zur Verfügung.
2. Websitedefinitionen erfordern eine WebTemp*.xml-Datei und können deshalb nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. Sie können jedoch benutzerdefinierte Websitetypen in Lösungen mit eingeschränkter Sicherheitsstufe mithilfe eines WebTemplate-Elements anstelle einer WebTemp*.xml-Datei bereitstellen. Weitere Informationen finden Sie unter How to: Deploy a Web Template in a Sandboxed Solution. 3. Ressourcendateien (RESX) können nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden, aber es gibt Möglichkeiten, Lösungen mit eingeschränkter Sicherheitsstufe zu lokalisieren, ohne Ressourcendateien im Serverdateisystem bereitzustellen. Weitere Informationen finden Sie unter Lokalisierung von Sandkastenlösungen. 4. Web.config-Dateien können nicht mit einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden, noch können sie geändert werden. Dasselbe gilt für ergänzende CONFIG-Dateien. Weitere Informationen finden Sie unter Gewusst wie: Erstellen einer ergänzenden .config-Datei. In Verbindung mit der Nichtverfügbarkeit der SPWebConfigModification-Klasse (siehe weiter unten in diesem Thema) bedeutet dies, dass Einstellungen für web.config in einer Lösung mit eingeschränkter Sicherheitsstufe nicht geändert werden können. |
Mit Code im Prozess sind keine Aufrufe im Netzwerk möglich. |
Der Zugriff ist nur auf Ressourcen möglich, die auf dem Server verfügbar sind, auf dem der Sandkastenarbeitsprozess ausgeführt wird. beispielsweise kann nicht auf eine externe Datenbank zugegriffen werden. Dies bedeutet, dass ein BCS-Modell nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden kann. |
Mit Code im Prozess kann nicht in die Registrierung geschrieben werden. |
|
Mit Code im Prozess können keine Assemblys aufgerufen werden, die nicht im globalen Assemblycache bereitgestellt sind. (Eine Ausnahme zu dieser Regel sind Assemblys, die im Rahmen der Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. Weitere Informationen finden Sie unter Wo werden Assemblys in Sandkastenlösungen bereitgestellt?) |
Microsoft SharePoint Foundation- und SharePoint Server-Assemblys, die nicht im globalen Assemblycache installiert sind, können nicht von Code aufgerufen werden, der im Sandkastenarbeitsprozess ausgeführt wird. Beispielsweise kann die Microsoft.SharePoint.UserCode.dll-Assembly nicht aufgerufen werden. |
Wichtig |
---|
Das Sicherheitstoken des Sandkastenarbeitsprozesses gilt nicht für Aufrufe von APIs in der Datei Microsoft.SharePoint.dll, da diese APIs in einem separaten, voll vertrauenswürdigen Prozess ausgeführt werden. Beispielsweise hindert die Tatsache, dass das Sicherheitstoken für den Sandkastenarbeitsprozess den Zugriff auf externe Datenbanken blockiert, eine Lösung mit eingeschränkter Sicherheitsstufe nicht am Zugriff auf eine externe Liste in einer SharePoint-Website. Auch der Zugriff auf eine standardmäßige SharePoint-Liste wird nicht blockiert, wenn sich die Inhaltsdatenbank auf einem anderen als dem Server, von dem die Lösung mit eingeschränkter Sicherheitsstufe verwaltet wird, befindet. Weitere Informationen finden Sie unter Architektur von Sandkastenlösungen. |
Restriktive Richtlinie für die Codezugriffssicherheit für den Sandkastenarbeitsprozess
Die Richtlinie für die Codezugriffssicherheit (Code Access Security, CAS) für den Arbeitsprozess der Lösung mit eingeschränkter Sicherheitsstufe wird in der Datei %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG\wss_usercode.config definiert, und es wird in der Datei web.config im Verzeichnis %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode darauf verwiesen. Mit dieser Richtlinie werden nur die in der folgenden Tabelle aufgelisteten Berechtigungen erteilt.
Erteilte Berechtigung |
Hinweise |
---|---|
Nicht jede Klasse im Objektmodell ist jedoch im Sandkastencode verfügbar. Weitere Informationen finden Sie im Abschnitt Spezielle Versionen der Microsoft.SharePoint.dll-Assembly weiter unten in diesem Thema. |
|
Die minimale Berechtigungsstufe erlaubt die Ausführung von Ressourcen, aber nicht den Lese-/Schreibzugriff auf Ressourcen oder sonstige Berechtigungen für die Ressourcen. Aufrufe von nicht verwaltetem Code sind nicht zulässig. |
Die folgende Tabelle enthält eine Auswahl von Berechtigungen, die nicht von der CAS-Richtlinie erteilt werden.
Verweigerte Berechtigung |
Hinweise |
---|---|
Wenn diese Berechtigung nicht vorhanden ist, wird Sandkastencode der Lese-/Schreibzugriff auf das Dateisystem verweigert. Dasselbe Recht wird auch vom Sicherheitstoken des Sandkastenarbeitsprozesses verweigert. |
|
Wenn diese Berechtigung nicht vorhanden ist, wird Sandkastencode der Zugriff auf die ASP.NET Reflection-APIs und damit auf nicht öffentliche Klassen und Member in verwaltetem Code verweigert. |
|
Wenn diese Berechtigung nicht vorhanden ist, wird Sandkastencode der Zugriff auf die Registrierung verweigert. Dasselbe Recht wird auch vom Sicherheitstoken des Sandkastenarbeitsprozesses verweigert. |
|
Wenn diese Berechtigung nicht vorhanden ist, wird Sandkastencode der Zugriff auf nicht verwalteten Code und auf die Threading- und Anwendungsdomänenteilsysteme verweigert. Außerdem wird nicht autorisiertem Code das Umgehen der Einschränkungen der CAS-Richtlinie erschwert. |
|
Wenn diese Berechtigung nicht vorhanden ist, kann mit Code in der Lösung mit eingeschränkter Sicherheitsstufe nicht auf die SharePoint-Datenbanken zugegriffen werden. Eine Ausnahme zu dieser Regel ist, dass mit Code zum Aufrufen der Datei Microsoft.SharePoint.dll auf die Datenbanken zugegriffen werden kann, vorausgesetzt der Aufruf ist für die speziellen Versionen dieser Assembly zulässig. Weitere Informationen zu diesen speziellen Assemblys und deren Rolle finden Sie unter Spezielle Versionen der Microsoft.SharePoint.dll-Assembly weiter unten in diesem Thema.
Wichtig
Für Aufrufe von APIs in anderenSharePoint Foundation- und SharePoint Server-Assemblys als Microsoft.SharePoint.dll wird aufgrund dieser Einschränkung oft ein Fehler gemeldet, selbst wenn sich die Assembly im globalen Assemblycache befindet und das AllowPartiallyTrustedCallers-Attribut aufweist. Nur Microsoft.SharePoint.dll verfügt über die speziellen Versionen, die Aufrufe erlauben, um den Sandkastenarbeitsprozess zu umgehen und in einem voll vertrauenswürdigen Prozess ausgeführt zu werden.
|
|
Weitere Informationen zu CAS-Richtlinien finden Sie unter Verwenden der Codezugriffssicherheit mit ASP.NET, Sicherheitsrichtlinien für .NET Framework 2.0 und Codezugriffssicherheit in der Praxis.
Wichtig |
---|
Die CAS-Richtlinie des Sandkastenarbeitsprozesses gilt nicht für Aufrufe von APIs in der Datei Microsoft.SharePoint.dll, da diese APIs in einem separaten, voll vertrauenswürdigen Prozess ausgeführt werden. Beispielsweise kann mit einem Aufruf von GetLocalizedString aus Ressourcendateien im Dateisystem gelesen werden. Weitere Informationen finden Sie unter Architektur von Sandkastenlösungen. |
Hinweis |
---|
Die CAS-Richtlinie macht für Microsoft Office-Assemblys mit starkem Namen eine Ausnahme. Sie werden als voll vertrauenswürdig behandelt. |
Assemblys ohne das AllowPartiallyTrustedCallers-Attribut können nicht aufgerufen werden
Eine CAS-Richtlinie, die Code im Sandkastenarbeitsprozess weniger als die volle Vertrauenswürdigkeit erteilt, weist unabhängig von den Richtliniendetails einen wichtigen Nebeneffekt auf: Mit dem von der CAS-Richtlinie gesteuerten Code können nur Assemblys mit dem AllowPartiallyTrustedCallersAttribute-Attribut aufgerufen werden. Mit Code im Sandkastenarbeitsprozess können demnach keine Assemblys aufgerufen werden, einschließlich Microsoft .NET Framework-, SharePoint Foundation- und SharePoint Server-Assemblys, denen dieses Attribut fehlt. In der folgenden Tabelle finden Sie Hinweise zu einigen Auswirkungen dieser Einschränkung.
Assembly ohne AllowPartiallyTrustedCallers-Attribut |
Auswirkungen und Hinweise |
---|---|
Microsoft.SharePoint.WorkflowActions |
Codierte Workflows können nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden, da solche Workflows den Zugriff auf Klassen in dieser Assembly benötigen. (Workflows ohne Code, die in Microsoft SharePoint Designer erstellt und möglicherweise in Visual Studio geändert wurden, können in Lösungen mit eingeschränkter Sicherheitsstufe bereitgestellt werden.) |
Eine Aufstellung der verfügbaren und nicht verfügbaren .NET Framework- und SharePoint-Assemblys finden Sie unter Verfügbare und nicht verfügbare .NET-Assemblys in Sandkastenlösungen und Verfügbare und nicht verfügbare SharePoint-Assemblys in Sandkastenlösungen.
Spezielle Versionen der Microsoft.SharePoint.dll-Assembly
Wie in Architektur von Sandkastenlösungen erläutert, werden Aufrufe von Microsoft.SharePoint.dll über Code im Sandkastenarbeitsprozess an eine spezielle Version dieser Assembly umgeleitet. Diese spezielle Version verfügt einerseits über weniger Rechte als andere Assemblys im Sandkastenarbeitsprozess, aber andererseits auch über mehr Rechte.
Die wichtigste Einschränkung ist, dass die spezielle Version nur eine Teilmenge der Klassen und Methoden der Standardassembly enthält. Eine Ausnahme wird ausgelöst, wenn mit Code eine API aufgerufen wird, die nicht in der speziellen Version der Assembly enthalten ist. In der folgenden Tabelle sind ein paar der APIs aufgeführt, die nicht in der speziellen Version der Assembly enthalten sind. Eine vollständige Liste der Klassen, die enthalten sind, finden Sie unter In Sandkastenlösungen verfügbare Microsoft.SharePoint.dll-APIs.
Blockierte API |
Auswirkungen und Hinweise |
---|---|
Die meisten Klassen des Microsoft.SharePoint.Administration-Namespaces, einschließlich der Klassen SPWebApplication und SPFarm. |
1. Features einer Lösung mit eingeschränkter Sicherheitsstufe können nicht im Bereich Farm oder WebApplication bereitgestellt werden. Deshalb können Features, die nur in diesen Bereichen bereitgestellt werden können, überhaupt nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. Beispielsweise kann ein Business Data Connectivity-Modell nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. 2. Nahezu keine Objekte und Ressourcen oberhalb der Websitesammlungsebene im Objektmodell sind für Lösungen mit eingeschränkter Sicherheitsstufe verfügbar. 3. Dokumentkonverter, die für die Webanwendung registriert sind, können nicht in einer Lösung mit eingeschränkter Sicherheitsstufe registriert werden. |
Alle Steuerelementklassen im Microsoft.SharePoint.WebControls-Namespace. |
Code in Sandkastenlösungen ist auf ASP.NET-Steuerelemente beschränkt. |
Die WebPartMobileAdapter-Klasse. |
Sandkastencode darf keinen mobilen Webpartadapter enthalten. |
Die Microsoft.SharePoint.WebPartPages.WebPart-Klasse. |
Sandkastenlösungen dürfen nur von der ASP.NET-Klasse System.Web.UI.WebControls.WebParts.WebPart abgeleitete Webparts enthalten. |
Zeitgeberaufträge dürfen nicht in Lösungen mit eingeschränkter Sicherheitsstufe enthalten sein. |
|
Einstellungen für die Datei web.config können nicht programmgesteuert für eine Lösung mit eingeschränkter Sicherheitsstufe geändert werden. Aufgrund der Tatsache, dass von Lösungen mit eingeschränkter Sicherheitsstufe weder das Dateisystem des Servers gelesen noch in dieses geschrieben werden kann (siehe weiter oben in diesem Thema), können Sie Einstellungen für die Datei web.config in einer Lösung mit eingeschränkter Sicherheitsstufe nicht ändern. |
|
Die Methoden in einer Lösung mit eingeschränkter Sicherheitsstufe können nicht so konfiguriert werden, dass sie mit den erhöhten Berechtigungen der Benutzeridentität ausgeführt werden, mit der der Anwendungspool ausgeführt wird. |
Selbst wenn eine Methode in der speziellen Version der Assembly enthalten ist, können zusätzliche Einschränkungen für die an die API übergebenen Parameter auferlegt werden. Beispielsweise sind die Konstruktoren SPSite(String) und SPSite(Guid) für Lösungen mit eingeschränkter Sicherheitsstufe verfügbar, aber nur URLs oder GUIDs, die auf die Websitesammlung verweisen, in der die Lösung mit eingeschränkter Sicherheitsstufe installiert ist, können an diese übergeben werden. Dadurch wird verhindert, dass eine Lösung mit eingeschränkter Sicherheitsstufe auf Websites, Listen oder sonstige Ressourcen von außerhalb der Websitesammlung zugreift, in der sie installiert wurde.
Aufrufe von Microsoft.SharePoint.dll, die durch den Gatekeeper der speziellen Assembly zulässig sind, sind jedoch im Vergleich zu Aufrufen von allen anderen Assemblys bezüglich eines wichtigen Aspekts privilegierter: Die aufgerufene API wird nicht im eingeschränkten Sandkastenarbeitsprozess ausgeführt. Stattdessen wird der Aufruf an einen voll vertrauenswürdigen Proxyprozess weitergeleitet, von dem die API ohne Einschränkung ausgeführt wird. Derartige Aufrufe ermöglichen demnach Aktionen, wie z. B. den Zugriff auf die SharePoint-Datenbanken, die mit Aufrufen von allen anderen Assemblys nicht möglich sind, nicht einmal von anderen SharePoint-Assemblys.
Getrenntes Seitenrenderingsystem
In Architektur von Sandkastenlösungen wurde bereits beschrieben, dass wenn ein Clientcomputer eine SharePoint-Seite anfordert, die eine Komponente aus einer Lösung mit eingeschränkter Sicherheitsstufe enthält, wie z. B. ein in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestelltes Webpart, von SharePoint mehrere Seitenobjekte gerendert werden. Ein Seitenobjekt wird im ASP.NET-Arbeitsprozess (w3wp.exe) gerendert, und die anderen Seitenobjekte werden im Sandkastenarbeitsprozess gerendert. Alle Nicht-Sandkastenkomponenten werden auf der Seite im ASP.NET-Arbeitsprozess gerendert, während die erste Sandkastenkomponente in einem Seitenobjekt des Sandkastenarbeitsprozesses gerendert wird. Wenn die Seite im Sandkastenarbeitsprozess vollständig gerendert ist, wird sie im ASP.NET-Prozess mit dem Seitenobjekt zusammengeführt. Falls mehrere Sandkastenkomponenten auf der Seite vorhanden sind, die der Benutzer angefordert hat, werden sie separat in einem eigenen Seitenobjekt des Sandkastenarbeitsprozesses gerendert. Jedes dieser Seitenobjekte wird wiederum im ASP.NET-Prozess mit dem Seitenobjekt zusammengeführt.
Dieses System bewirkt unter anderem, dass ein in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestelltes Webpart weder ein Anbieter- noch ein Consumerwebpart in einer Webpartverbindung sein kann. Dies liegt daran, dass jedes Sandkastenwebpart vollständig in einem separaten Seitenobjekt gerendert. (Seitenübergreifende Webpartverbindungen sind bei von der Microsoft.SharePoint.WebPartPages.WebPart-Klasse abgeleiteten Webparts möglich, aber diese Klasse wird durch den Shim Microsoft.SharePoint.dll blockiert – siehe weiter oben in diesem Thema. Nur von der System.Web.UI.WebControls.WebParts.WebPart-Klasse abgeleitete Webparts werden in Lösungen mit eingeschränkter Sicherheitsstufe unterstützt, und für diese Webparts sind keine seitenübergreifenden Webpartverbindungen zulässig.)
Das getrennte Seitenrenderingsystem wirkt sich noch anderweitig aus. Manche ASP.NET-Typen können nicht von einem Seitenobjekt im Sandkastenprozess mit der zurückgegebenen endgültigen Seite zusammengeführt werden. Daher wäre es für Code in einer Lösung mit eingeschränkter Sicherheitsstufe sinnlos, in Eigenschaften des ASP.NET-Objekts Page (oder dessen untergeordnete Objekte) zu schreiben, in denen Objekte dieser nicht zusammenführbaren Typen enthalten sind. In der folgenden Tabelle werden einige dieser Typen beschrieben.
Nicht zusammenführbarer Typ |
Auswirkungen und Hinweise |
---|---|
Mit Sandkastencode sollte nicht in die ClientScript-Eigenschaft geschrieben werden. Clientseitiges Script kann jedoch für die Seite auf andere Weise registriert werden. Beispielsweise könnten Sie das Skript als LiteralControl einbetten und einer Steuerelementauflistung in einer CreateChildControls()-Methode hinzufügen. |
|
Mit Sandkastencode sollte ein ScriptManager-Objekt nicht der Steuerelementauflistung eines beliebigen Objekts hinzufügt werden. |
|
Mit Sandkastencode sollte nicht in die Cache-Eigenschaft geschrieben werden. |
|
Mit Sandkastencode sollte nicht in die Master-Eigenschaft geschrieben werden. Die Seite kann jedoch auf eine andere Gestaltungsvorlage verwiesen werden, indem in die MasterPageFile-Eigenschaft geschrieben wird. |
|
Mit Sandkastencode sollte nicht in die Session-Eigenschaft geschrieben werden. |
Einschränkungen beim Ressourceneinsatz
Die Systemressourcen dürfen von Sandkastenlösungen nicht übermäßig verwendet werden. Diese Anforderung wird durch SharePoint Foundation-Ressourcenüberwachungsinfrastruktur erzwungen.
Weitere Informationen finden Sie unter Einschränkungen beim Ressourceneinsatz in Sandkastenlösungen und Architektur von Sandkastenlösungen.
Farmbezogene Validierung von Lösungen
Farmadministratoren können wie in Solution Validation System beschrieben die benutzerdefinierte Lösungsvalidierung für Lösungen mit eingeschränkter Sicherheitsstufe konfigurieren. Dadurch können zusätzliche Einschränkungen für die Aktionen, die von einer Lösung mit eingeschränkter Sicherheitsstufe ausgeführt werden können, auferlegt werden. Sie müssen von den Farmadministratoren herausfinden, welche Validierer sie verwenden.
Farmbezogene Blockierung von Lösungen
Farmadministratoren können jede Lösung mit eingeschränkter Sicherheitsstufe einer Liste blockierter Lösungen in der Zentraladministration hinzufügen.
Farmbezogene Blockierung von Klassen
Farmadministratoren können benutzerdefinierten Code ausführen, mit dem verhindert wird, dass angegebene verwaltete Klassen im Sandkastenarbeitsprozess aufgerufen werden. Weitere Informationen finden Sie unter SPRestrictedObjectModel.
Verschiedene Einschränkungen
In der folgenden Tabelle werden Einschränkungen für Lösungen mit eingeschränkter Sicherheitsstufe aufgelistet, die nicht eindeutig den anderen Abschnitten in diesem Thema zugeordnet werden können.
Einschränkung |
Auswirkungen und Hinweise |
---|---|
Ein HideCustomAction-Element kann nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. |
Sie können nicht mithilfe einer Lösung mit eingeschränkter Sicherheitsstufe ein Menüelement, eine Menübandschaltfläche oder einen Link auf einer Verwaltungsseite, wie z. B. auf der Seite Websiteeinstellungen, ausblenden. Allerdings können Sie diesen Komponenten mithilfe einer Lösung mit eingeschränkter Sicherheitsstufe eine neue benutzerdefinierte Aktion hinzufügen. Weitere Informationen finden Sie unter Möglichkeiten und Einschränkungen von Sandkastenlösungen. |
Ein CustomActionGroup-Element kann nicht in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt werden. |
Sie können zwar eine neue benutzerdefinierte Aktion in einer Lösung mit eingeschränkter Sicherheitsstufe hinzufügen, aber Sie können keine neue Aktionsgruppe für Ihre benutzerdefinierten Aktionen erstellen. Weitere Informationen finden Sie unter Möglichkeiten und Einschränkungen von Sandkastenlösungen. |
Sie können einen Steuerelementkandidaten nicht für ein Stellvertretungs-Steuerelement (Control-Element) in einer Lösung mit eingeschränkter Sicherheitsstufe registrieren. |
Siehe auch
Konzepte
Möglichkeiten und Einschränkungen von Sandkastenlösungen