Freigeben über

<behaviorExtensions>

Verhaltenserweiterungen ermöglichen es dem Benutzer, benutzerdefinierte Verhaltenselemente zu erstellen. Diese Elemente können zusammen mit den standardmäßigen Windows Communication Foundation (WCF)-Verhaltenselementen verwendet werden. Der behaviorExtensions Abschnitt definiert das Element so, dass es in der Konfiguration verwendet werden kann. Hier ist ein Beispiel für eine typische Verhaltenserweiterung.

<system.serviceModel>
  <extensions>
    <behaviorExtensions>
      <add name="myBehavior"
           type="Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
                 Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </behaviorExtensions>
  </extensions>
</system.serviceModel>

Um dem Element Konfigurationsfähigkeiten hinzuzufügen, müssen Sie ein Konfigurationselement schreiben und registrieren. Weitere Informationen hierzu finden Sie in der System.Configuration Dokumentation.

Nachdem das Element und sein Konfigurationstyp definiert wurden, kann die Erweiterung verwendet werden, wie im folgenden Beispiel gezeigt.

<behaviors>
  <behavior configurationName="testChannelBehavior">
    <myBehavior />
    <channelSecurity cacheCookies="false"
                     detectReplays="false"
                     maxCachedNonces="9"
                     maxClockSkew="00:00:03"
                     maxCookieCachingTime="00:07:24"
                     replayWindow="00:07:22.2190000" />
  </behavior>
</behaviors>

Sicherheit

Es wird dringend empfohlen, beim Registrieren von Typen in den machine.config und app.config Dateien vollqualifizierte Assemblynamen zu verwenden. Wenn der Typ nicht eindeutig definiert ist, sucht das CLR-Typladeprogramm an den folgenden Speicherorten in der angegebenen Reihenfolge danach:

Wenn die Assembly des Typs bekannt ist, durchsucht das Ladeprogramm die Umleitungsspeicherorte der Konfigurationsdatei, GAC, die aktuelle Assembly mit Konfigurationsinformationen und das Anwendungsbasisverzeichnis. Wenn die Assembly unbekannt ist, durchsucht das Ladeprogramm die aktuelle Assembly, mscorlib und den vom TypeResolve Ereignishandler zurückgegebenen Speicherort. Diese CLR-Suchreihenfolge kann mit Hooks wie dem Type Forwarding-Mechanismus und dem AppDomain.TypeResolve-Ereignis geändert werden.

Ein Angreifer kann die CLR-Suchreihenfolge ausnutzen und nicht autorisierten Code ausführen. Die Verwendung vollqualifizierter (sicherer) Namen ermöglicht die eindeutige Identifizierung eines Typs und trägt zur Verbesserung der Systemsicherheit bei.

Weitere Informationen finden Sie unter How the Runtime Locates Assemblies and TypeResolve.

Siehe auch

  • Last updated on