Partager via

<behaviorExtensions>

Les extensions de comportement permettent à l’utilisateur de créer des éléments de comportement définis par l’utilisateur. Ces éléments peuvent être utilisés en même temps que les éléments de comportement Windows Communication Foundation (WCF) standard. La behaviorExtensions section définit l’élément tel qu’il peut être utilisé dans la configuration. Voici un exemple d’extension de comportement classique.

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

Pour ajouter des capacités de configuration à l’élément, vous devez écrire et inscrire un élément de configuration. Pour plus d’informations sur ce problème, consultez la System.Configuration documentation.

Une fois l’élément et son type de configuration définis, l’extension peut être utilisée, comme illustré dans l’exemple suivant.

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

Security

Il est fortement recommandé d’utiliser des noms d’assemblys complets lors de l’inscription de types dans les fichiers et machine.config les app.config fichiers. Si le type n’est pas défini de manière unique, le chargeur de type CLR le recherche dans les emplacements suivants dans l’ordre spécifié :

Si l’assembly du type est connu, le chargeur recherche les emplacements de redirection du fichier de configuration, GAC, l’assembly actuel à l’aide des informations de configuration et du répertoire de base de l’application. Si l’assembly est inconnu, le chargeur recherche l’assembly actuel, mscorlib et l’emplacement retourné par le TypeResolve gestionnaire d’événements. Cet ordre de recherche CLR peut être modifié avec des hooks tels que le mécanisme de transfert de type et l’événement AppDomain.TypeResolve.

Un attaquant peut exploiter l’ordre de recherche CLR et exécuter du code non autorisé. L’utilisation de noms complets (forts) identifie de manière unique un type et renforce considérablement la sécurité de votre système.

Pour plus d’informations, consultez Comment le runtime localise les assemblys et TypeResolve.

Voir aussi

  • Last updated on