Problème deploiement Web Service

**Nanais19** · 24/04/2013, 17h42

Bonjour,

J'ai développé un web service WCF avec une liaison WSDualHttpBinding et qui utilise l'authentification via userName / password et la classe UserNamePasswordValidator.

J'ai également développé une appli cliente qui appel le web service pour s'authentifier et qui passe donc par ma méthode "validate".

Tous fonctionne très bien en local.

J'ai fait un test de deploiement :

- Web service + appli cliente sur la même machine (=tous va bien)

- Web service + appli cliente sur une autre machine (=échec)

J'arrive pourtant de mon appli cliente sur une autre machine à accéder à mon web service, j'arrive à afficher le fichier wsdl et aucune erreur ne m'est retourné lorsque j'appelle une méthode de mon web service sauf un time out me signalant que le temps d'attente de la réponse est dépassé.

J'ai donc attaché visual studio au processus de mon web service pour le debuguer et refait un test de connexion en local (dans ce cas tous ce passe bien et je passe dans ma méthode validate), puis je refait un test depuis mon autre machine et là rien ne se passe (je ne passe jamais dans ma méthode validate et ne retourne jamais aucune réponse).

N'ayant aucun message d'erreur je n'arrive pas à cerner le problème. Si vous auriez des pistes de réflexion à me faire par je suis preneuse.

Merci d'avance.

**mkl238** · 25/04/2013, 10h09

Bonjour,

si tu es sur un réseau d'entreprise, vérifie qu'il n'y a pas un firewall qui bloque tes requêtes et/ou que tu ne passes pas par un proxy auquel cas tu devras adapter les attributs useDefaultWebProxy, bypassProxyOnLocal ... de l'élément binding de ton client.

**Nanais19** · 25/04/2013, 13h45

J'ai fait un test de connexion entre une machine cliente et un serveur iis distant avec les firewall désactiver pour faire mes test.

Apparemment mon soucis viens du fait que a distance on doit configurer la propriété clientbaseadress.

J'ai donc refait le test avec cette config mais j'ai toujours le même résultat (timeout)

J'ai fait un test en conservant la configuration initiale de mon serveur qui est celle ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
<system.serviceModel>
    <services>
      <service name="WS.ServiceProduits" behaviorConfiguration="behaviorConfig">
        <endpoint address="" binding="wsDualHttpBinding" bindingConfiguration="wsDualHttp" contract="WS.Interface.IProduits">
          <identity>
            <dns value="CertServerProduits"/>
          </identity>
        </endpoint>
      </service>
    </services>
    <bindings>
      <wsDualHttpBinding>
        <binding name="wsDualHttp">
          <security mode="Message">
            <message clientCredentialType="UserName" />            
          </security>
        </binding>
      </wsDualHttpBinding>
    </bindings>
<behaviors>
      <serviceBehaviors>
        <behavior name="behaviorConfig">
          <!-- To avoid disclosing metadata information, set the values below to false before deployment -->
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceCredentials>
            <clientCertificate>
              <authentication certificateValidationMode="None" revocationMode="NoCheck" />
            </clientCertificate>
            <serviceCertificate storeName="My" storeLocation="LocalMachine" x509FindType="FindBySubjectName" findValue="CertServerProduits" />
            <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="WS.CustomUserNameValidator, WS" />
          </serviceCredentials>
          <serviceAuthorization principalPermissionMode="Custom">
            <authorizationPolicies>
              <add policyType="WS.CustomAuthorizationPolicy, WS" />
            </authorizationPolicies>
          </serviceAuthorization>
        </behavior>
      </serviceBehaviors>
    </behaviors>

Et j'ai modifié mon fichier de configuration client de la façon suivante, pour utiliser la propriété clientbaseadress :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
<bindings>
            <wsDualHttpBinding>
                <binding name="WSDualHttpBinding_Config"  clientBaseAddress="http://IPClient:8085/">
                    <security>
                        <message clientCredentialType="UserName" />
                    </security>
                </binding>
            </wsDualHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://IPServer/WS/ServiceProduits.svc" behaviorConfiguration="myClientBehavior"
                binding="wsDualHttpBinding" bindingConfiguration="WSDualHttpBinding_Config"
                contract="ServiceReference1.Produits" name="WSDualHttpBinding_Produits">
                <identity>
                    <dns value="CertServerProduits" />
                </identity>
            </endpoint>
        </client>
      <behaviors>
        <endpointBehaviors>
          <behavior name="myClientBehavior">
            <clientCredentials>
              <serviceCertificate>
                <authentication certificateValidationMode="None" revocationMode="NoCheck"/>
              </serviceCertificate>
            </clientCredentials>
          </behavior>
        </endpointBehaviors>
      </behaviors>

**DotNetMatt** · 25/04/2013, 14h00

~~Sous quel OS tourne le client ?~~

[EDIT] : Il y a de fortes chances pour que les timeout proviennent d'un problème localisé sur le réseau. On ne connait pas la topologie du réseau sur lequel tu travailles, mais il faut tenir compte du fait que si tu as un firewall entre le client et le serveur, il peut y avoir des règles NAT dans les deux sens :

Client ==> Firewall ==> Serveur
Client <== Firewall <== Serveur

C'est un premier point à vérifier. Il peut également y avoir un routeur + des règles NAT, qui pourraient empêcher tout callback. Mais bon il n'y a que toi qui peut le savoir....

Ensuite, pour utiliser wsDualHttpBinding il faut s'assurer que la connexion n'est jamais interrompue entre le client et le serveur, car ça fonctionne sur un principe de session. Voir ici pour plus d'infos : http://www.dotnetconsult.co.uk/weblo...1363fa51e.aspx ou là : http://blogs.msdn.com/b/ralph.squill...-no_2e00_.aspx

Si tu n'arrives pas à trouver de solution, tu peux rajouter un composant entre ton serveur et ton client : le Service Bus Relay Service, qui fait partie de la plateforme Azure.
Ca permet de simplifier la communication et de s'affranchir de la configuration des firewalls et du NAT, mais ça demande de passer par Azure.

**Nanais19** · 25/04/2013, 16h13

Pour le moment on est juste "en local" c'est a dire que j'ai une machine qui est monté exprès pour les test où il n'y a rien dessus à par mon web service et j'essaie d'y accéder depuis mon PC où j'ai mon appli cliente.

J'ai désactiver les firewall de mon PC ainsi que celui de la machine test et il n'y a pas de routeur ni de règle NAT de spécifier en particulier sur mon réseau.

[EDIT] : Je n'ai pas encore regardé les liens, je vais le faire de suite.

**Nanais19** · 25/04/2013, 16h49

Pour info, j'utilise un server IIS sur windows 7, par conséquent l'utilisation de Service Bus Relay Service sur windows azure n'est pas possible dans ma situation.

**DotNetMatt** · 25/04/2013, 16h55

Si tu lances une commande telnet depuis ton serveur vers ton client, sur le port que tu veux utiliser, est-ce que ça fonctionne ?

Et si tu fais de même de ton client vers le serveur ?

**Nanais19** · 25/04/2013, 17h25

Bon j'ai activer telnet et fait les opérations suivantes :
Sur mon poste (poste client)

cmd>telnet ipserver 80
Résultat : une connexion est établie

Sur mon poste test (poste web service)

Essai 1, lancement de la commande sans faire de tentative de connexion avec mon appli cliente
cmd>telnet ipclient 8085
Résultat : connection failed (ce qui est normal, d'après ce que j'ai compris, que le port doit s'ouvrir lorsque l'appli cliente fait un appel au web service)

Essai 2, lancement d'un appel depuis mon appli cliente avec temps d'attente de réponse de 1 minute et de la commande dans la foulée
cmd>telnet ipclient 8085
Résultat : une connexion est établie

Apparemment mes machines communiquent bien ensemble, d’ailleurs je n'ai aucun problème pour accéder au fichier wsdl du serveur depuis un navigateur depuis ma machine cliente.

**DotNetMatt** · 25/04/2013, 17h29

Ok, merci pour ces infos. Si tu utilises un autre port que le port 80 sur ton serveur Web, as-tu toujours le timeout ?

Ca permettra de vérifier si IIS ne bloque rien au passage...

**Nanais19** · 25/04/2013, 19h25

C'est pas bête, je vais essayer ça demain matin. Je vous tiens au courant.
Merci

**Nanais19** · 26/04/2013, 09h55

Je n'arrive pas à utiliser autre chose que le port 80 !
Peut être pouvez vous me rappeler la bonne procédure pour que je vérifie

**DotNetMatt** · 26/04/2013, 10h18

Il faut modifier le web.config sur le serveur. Puis il faut s'assurer que le site IIS qui expose le Web Service soit bindé sur le port choisi.

Ensuite, il faut modifier le web.config du client pour lui indiquer ce même port.

Enfin, vérifier les firewalls (serveur, client, et entre les deux).

**Nanais19** · 26/04/2013, 11h04

Décidément je pense que j'ai encore raté quelque chose ! Pourtant j'avais bien suivit la procédure décrite et je viens de refaire un essaie sans succès.

j'ai modifié le fichier de configuration avec le port 8005 et j'ai ajouté le binding sur iis. Je tente alors d'afficher mon web service dans le navigateur pour vérifier que tous va bien et là patatra !

Voici le message d'erreur que j'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
When 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' is set to true in configuration, the endpoints are required to specify a relative address. If you are specifying a relative listen URI on the endpoint, then the address can be absolute. To fix this problem, specify a relative uri for endpoint 'http://***.***.***.***:8005/WS/ServiceProduits.svc'.

J'ai fini par réussir à faire le test en ne modifiant pas le fichier config de mon web service (donc en utilisant toujours des chemins relatifs) et en ajoutant juste la liaisons sur IIS vers le port 8005.
J'ai modifier le fichier de configuration de mon appli cliente pour qu'elle pointe aussi vers ce port.

Seulement le résultat est toujours le même ! Pas de messages d'erreurs explicite, juste un time out.

Pour rappel voici mon fichier config du web service :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
<system.serviceModel>
    <services>
      <service name="WS.ServiceProduits" behaviorConfiguration="behaviorConfig">
        <endpoint address="" binding="wsDualHttpBinding" bindingConfiguration="wsDualHttp" contract="WS.Interface.IProduits">
          <identity>
            <dns value="CertServerProduits"/>
          </identity>
        </endpoint>
		<endpoint address="" binding="wsDualHttpBinding" bindingConfiguration="wsDualHttp" contract="WS.Interface.IFournisseurs">
          <identity>
            <dns value="CertServerProduits"/>
          </identity>
        </endpoint>
      </service>
    </services>
    <bindings>
      <wsDualHttpBinding>
        <binding name="wsDualHttp">
          <security mode="Message">
            <message clientCredentialType="UserName" />            
          </security>
        </binding>
      </wsDualHttpBinding>
    </bindings>
<behaviors>
      <serviceBehaviors>
        <behavior name="behaviorConfig">
          <!-- To avoid disclosing metadata information, set the values below to false before deployment -->
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceCredentials>
            <clientCertificate>
              <authentication certificateValidationMode="None" revocationMode="NoCheck" />
            </clientCertificate>
            <serviceCertificate storeName="My" storeLocation="LocalMachine" x509FindType="FindBySubjectName" findValue="CertServerProduits" />
            <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="WS.CustomUserNameValidator, WS" />
          </serviceCredentials>
          <serviceAuthorization principalPermissionMode="Custom">
            <authorizationPolicies>
              <add policyType="WS.CustomAuthorizationPolicy, WS" />
            </authorizationPolicies>
          </serviceAuthorization>
        </behavior>
      </serviceBehaviors>
    </behaviors>
</system.serviceModel>

Pour info j'ai vérifier la connexion avec telnet une nouvelle fois avec les nouveaux port et il n'y avait pas de soucis non plus !

C'est quand même étrange que à l'appel de la méthode, j'arrive à constater que une instance du web service est créé s'il n'y en a pas mais que celui ci ne réceptionne pas la requête car il ne rentre jamais dans aucune méthode du web service, même pas ma méthode validate.

[EDIT] : les firewalls sont bien désactivés sur la machine cliente et sur la machine du webservice.

**DotNetMatt** · 26/04/2013, 11h10

Hmmh... Est-ce que tu peux utiliser un outil comme Fiddler afin d'intercepter les requêtes et voir s'il n'y a pas une erreur ?

Sinon, active aussi la trace grâce à la méthode décrite ici : http://www.zied.fr/2010/03/07/DebuggerUnServiceWCF.aspx

On y verra peut-être plus clair.

**Nanais19** · 26/04/2013, 11h47

Aaaahhhh !!

Je viens de découvrir la cause de tout ça !!
Dans le fichier de log, j'ai vu le message d'erreur suivant :

The security timestamp is stale because its expiration time ('2013-04-26T09:34:21.303Z') is in the past. Current time is '2013-04-26T10:29:14.375Z' and allowed clock skew is '00:05:00'.

Je suis donc allée voir l'heure indiqué sur ma machine du web service et j'ai constaté qu'on avait une heure de décalage entre celle ci et ma machine !
J'ai donc changé l'heure de la machine du web service et là !! Surprise tout fonctionne à nouveau !

Je ne pensais pas du tout que ceci pouvait poser problème ! Comment sont gérés les web services appelés depuis l'étranger avec des décalages horaires importants ?
Y a t'il un paramétrage a effectué pour éviter ce genre de conflit ?

**DotNetMatt** · 26/04/2013, 12h03

Ahhhh

C'est vrai qu'on n'y pense pas souvent mais les désynchronisations d'horloge peuvent causer des soucis...

Là le message d'erreur indique tu as un décalage sur le nombre de minutes, et que la tolérance est de 5 minutes maximum. Si les minutes et secondes sont bien synchronisées (dans le slot toléré de +/- 5 minutes), je pense que le fuseau horaire est géré sans problème automatiquement.

Mais bon je ne suis pas certain à 100% de ce que j'avance sur ce sujet.

[EDIT] : a lire pour information : http://webservices20.blogspot.fr/201...ks-in-wcf.html

[EDIT2] : après avoir farouillé sur le net à ce sujet, il s'avère que même si les serveurs sont parfaitement synchronisés, le problème peut se produire à cause d'une latence du réseau. Autre lien à voir : http://sandrinodimattia.net/blog/pos...kskew-quickly/

**Nanais19** · 26/04/2013, 14h11

Au moment où j'ai découvert la différence de plage horaire et que je l'ai modifié j'ai refait un test en lançant mon application cliente et ça a marché. J'ai réussi à me connecté.

Pour le plaisir j'en ai fait un deuxième sa à planté.
Effectivement l'heure c'était resynchronisé sur la machine du service j'ai donc décoché la case de synchronisation et remis la bonne heure pour retesté.

Et depuis sa ne marche à nouveau plus et j'ai toujours ce même message d'erreur dans mes logs.

Je vais creuser un peu plus le problèmes avec tes liens.
Merci beaucoup pour votre aide en tous cas.

Je continue de vous informé de la situation dès que j'ai du nouveau.

**Nanais19** · 26/04/2013, 14h40

Bon bé comme apparemment on est obligé de passer par la custumisation du binding pour augmenter le délai, je vai voir pour faire ça !

N'empêche que les horaires qu'il y a dans ces logs m’interpelle car par exemple mon dernier essaie je l'ai lancé à 14h04 (affichage de l'heure de ma machine cliente et de la machine du service !)
Et pourtant les logs je retrouve cette heure ci dans la propriété time :

Time 2013-04-26 15:04:27.9984

Et le message d'erreur est celui-ci :

The security timestamp is stale because its expiration time ('2013-04-26T12:09:35.374Z') is in the past. Current time is '2013-04-26T13:04:27.997Z' and allowed clock skew is '00:05:00'.

Je retrouve une différence de plus de 1h05 entre les deux. Et en plus dans les deux horaires affichés aucun ne correspond à l'heure que je voie moi.
12:09:35 et 13:04:27 au lieu de mon 14h04 affiché sur mes deux postes !

Sa fait beaucoup d'heures différentes, j'ai un peu de mal à comprendre ce qui ce passe !

**DotNetMatt** · 26/04/2013, 14h48

Ah oui les problèmes de fuseau horaire, ça peut être très chiant...

C'est un peu comme la gestion des langues (langue de travail, langue de restitution, etc.)...

Vérifie sur le serveur et le client s'il y a des différences dans les options régionales et linguistiques (panneau de config).

Tu peux aussi regarder s'ils sont configurés sur le même fuseau horaire.