web-dev-qa-db-fra.com

Comment utiliser Fiddler pour surveiller le service WCF

J'ai un service WCF qui accepte un type complexe et renvoie des données. Je veux utiliser Fiddler pour voir à quoi ressemblent les demandes entrantes au service. Le client est une application de console .net qui utilise un proxy de référence de service. Est-ce possible avec Fiddler. Cet outil est nouveau pour moi et je ne l’avais utilisé que par le passé pour publier des données avec le générateur de demandes.

103
Quadwwchs

Vous devez ajouter ceci dans votre web.config

<system.net>
  <defaultProxy>
    <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>
  1. puis Démarrer Fiddler sur la machine WEBSERVER.
  2. Cliquez sur Outils | Options de Fiddler => Connexions => ajustez le port sur 8888. (autorisez distant si vous en avez besoin)
  3. Ok, puis dans le menu Fichier, capturer le trafic.

C'est tout, mais n'oubliez pas de supprimer les lignes web.config après la fermeture du violoniste, sinon vous ferez une erreur.

Référence: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy

142
Tarek El-Mallah

Fiddler écoute les requêtes sortantes plutôt que les requêtes entrantes. Vous ne pourrez donc pas surveiller toutes les requêtes arrivant sur votre service à l'aide de Fiddler.

Le meilleur avantage que vous obtiendrez avec Fiddler est la possibilité de voir toutes les demandes telles qu'elles sont générées par votre application console (en supposant que l'application génère des requêtes Web plutôt que d'utiliser un autre pipeline).

Si vous voulez un outil plus puissant (mais plus difficile à utiliser) qui vous permettra de surveiller TOUTES les demandes entrantes, vous devriez jeter un coup d'œil à WireShark.

Modifier

Je me suis trompé. Merci à Eric Law pour l’affichage des instructions pour configuration de Fiddler comme proxy inverse !

8
Justin Niessner

Je viens d'avoir ce problème, ce qui a fonctionné pour moi a été d'utiliser localhost.fiddler:

 <endpoint address="http://localhost.fiddler/test/test.svc"
            binding="basicHttpBinding" 
            bindingConfiguration="customBinding" 
            contract="test" 
            name="customBinding"/>
8
L-Four

Consolidation des mises en garde mentionnées dans les commentaires/réponses pour plusieurs cas d'utilisation.

Principalement, voir http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp

  • Lancez Fiddler avant votre application
  • Dans une application de console, vous n'avez peut-être pas besoin de spécifier le proxyaddress:

    <proxy bypassonlocal="False" usesystemdefault="True" />
    
  • Dans une application Web/quelque chose hébergé dans IIS, vous devez ajouter le proxyaddress:

    <proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
    
  • Lorsque .NET fait une demande (via un client de service ou HttpWebRequest, etc.), il contourne toujours le proxy Fiddler pour les URL contenant localhost. Vous devez donc utiliser un alias tel que le nom de la machine ou make. quelque chose dans votre fichier 'hosts' (ce qui explique pourquoi quelque chose comme localhost.fiddler ou http://HOSTNAME travaux)
  • Si vous spécifiez le proxyaddress, vous devez le supprimer de votre configuration si Fiddler n'est pas activé, sinon les requêtes émises par votre application renverront une exception telle que:

    Aucune connexion n'a pu être établie car la machine cible l'a activement refusée 127.0.0.1:8888

  • N'oubliez pas d'utiliser transformations de configuration pour supprimer la section proxy en production
6
drzaus

Si simple, il suffit de changer l'adresse dans le client de configuration: au lieu de "localhost", changez le nom de l'ordinateur ou l'adresse IP.

4
Ziv.Ti

Suivi/diagnostics WCF standard

Si, pour une raison quelconque, vous ne parvenez pas à faire fonctionner Fiddler, ou si vous préférez consigner les demandes d’une autre manière, une autre option consiste à utiliser la fonctionnalité de suivi WCF standard. Cela produira un fichier qui a une belle visionneuse.

Docs

Voir https://docs.Microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging

Configuration

Ajoutez les éléments suivants à votre configuration, assurez-vous que c:\logs existe, reconstruit et effectue des requêtes:

  <system.serviceModel>
    <diagnostics>
      <!-- Enable Message Logging here. -->
      <!-- log all messages received or sent at the transport or service model levels -->
      <messageLogging logEntireMessage="true"
                      maxMessagesToLog="300"
                      logMessagesAtServiceLevel="true"
                      logMalformedMessages="true"
                      logMessagesAtTransportLevel="true" />
    </diagnostics>
  </system.serviceModel>

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Information,ActivityTracing"
        propagateActivity="true">
        <listeners>
          <add name="xml" />
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
          <add name="xml" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="C:\logs\TracingAndLogging-client.svclog" type="System.Diagnostics.XmlWriterTraceListener"
        name="xml" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>
1
Seth Flowers

C'est simple si vous avez le contrôle sur le client qui envoie les communications. Tout ce que vous avez à faire est de définir HttpProxy sur la classe de service côté client.

Je l'ai fait, par exemple, pour suivre un client de service Web exécuté sur un smartphone. J'ai défini le proxy sur cette connexion côté client sur l'IP/le port de Fiddler, qui fonctionnait sur un PC du réseau. L'application pour smartphone a ensuite envoyé toutes ses communications sortantes au service Web, via Fiddler.

Cela a parfaitement fonctionné.

Si votre client est un client WCF, alors consultez ce Q & A pour savoir comment définir le proxy.

Même si vous ne pouvez pas modifier le code de l'application côté client, vous pourrez peut-être définir le proxy de manière administrative, en fonction de la pile de services Web utilisée par votre client.

1
Cheeso

J'ai utilisé l'outil Shark Wire pour surveiller les appels de service depuis l'application Silver Light dans le navigateur. essayez le lien donne des informations claires

Il vous permet de surveiller l’ensemble du contenu de la demande et de la réponse.

0
DiAgo

Je viens d'essayer la première réponse de Brad Rem et suis arrivé à ce paramètre dans le web.config sous BasicHttpBinding:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding bypassProxyOnLocal="False" useDefaultWebProxy="false" proxyAddress="http://127.0.0.1:8888" ...
        ...
      </basicHttpBinding>
    </bindings>
    ...
<system.serviceModel>

J'espère que ça aide quelqu'un.

0
Remko Roodselaar