Discussion :

[Nisnor]

Bonjour à vous

[Hors Sujet]J'ai mis un titre un peu fantaisiste car je ne vois pas comment intituler mon problème[/Hors Sujet]

Le contexte

• J'ai une application Silverlight qui doit communiquer avec un service WCF via une liaison sécurisée. Silverlight étant assez limité au niveau des types de communications WCF, je dois utiliser du HTTP over SSL (HTTPS donc).
• J'ai un service WCF Self-hosted, a priori correctement configuré, qui propose deux points d'écoutes : Le premier est lié au service à proprement parlé et le second est un point d'écoute de type REST pour pouvoir diffuser le clientaccesspolicy.xml.
• Tout ce petit monde est installé sur un server 2008 R2 de test avec IIS. Dans IIS, il n'y a aucun site web (pour le moment) et sa configuration reste par défaut.
• Les ports requis sont correctement forwardés dans le routeur et sont aussi débloqués dans le firewall du serveur de test.
• J'ai généré un certificat racine et un certificat dont le CN est égal au domaine utilisé pour se connecter au service. Le certificat racine à été placé dans le magasin des certificat d'authorité racine de confiance et l'autre, dans le magasin personnel de l'utilisateur en cours et dans le magasin personnel de la machine (dès fois que)

Le problème

• Si je lance le service WCF et l'application silverlight tels quels, ça ne fonctionne pas. Silverlight génère une exception comme quoi il n'arrive pas à charger le fichier clientaccesspolicy.xml. Si je place un point d'arrêt dans la méthode de service retournant le fichier clientaccesspolicy.xml, celle-ci n'est effectivement pas appelée.
• Si je lance le service WCF, que j'ajoute sur le site créé par défaut dans IIS (qui est toujours vide, je vous le rappèle), le binding HTTPS suivit du port utilisé et que je lance l'application silverlight, tout fonctionne correctement...

La question qui tue
Quelqu'un pourrait-il m'expliquer le lien entre mon application de service self-hosted sur HTTPS et IIS???!?!?
Je soupçonne un problème de certificat...Mais pourquoi le fait de l'utiliser dans IIS (lors de l'ajout du binding HTTPS) permet à une application qui n'en dépend pas, de déchiffrer correctement les communications?!??!?

[Invité]

Je soupçonne la manière dont t'as implémenté la méthode REST crachant le fichier clientacccesspolicy.xml.

Code c# :

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

1
2
3
4
5
6
7
8
 
public System.ServiceModel.Channels.Message ProvidePolicyFile()
        {
            FileStream filestream = File.Open(@"ClientAccessPolicy.xml", FileMode.Open);
            XmlReader reader = XmlReader.Create(filestream);
            System.ServiceModel.Channels.Message result = Message.CreateMessage(MessageVersion.None, "", reader);
            return result;
        }

ton l'attribut WebGet de la méthode exposant la méthode doit ressembler à ça :

Code C# :

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

1
2
 
[WebGet(UriTemplate = "ClientAccessPolicy.xml")]

[Nisnor]

Merci d'avoir pris le temps de lire mon message et d'y répondre ^^.

En voyant ta version de la méthode de service REST, je me pose quelques petites questions :

• En effet, mon implémentation diffère un peu. Je n'utilise pas la classe "Message" de l'espace de nom Channels pour retourner la réponse. Suivant un article à ce sujet, j'ai juste spécifié que le type MIME de l'élément retourné est "text/xml" en UTF8 et je retourne directement un objet Stream. Je vais regarder ce que fait cette classe Message pour en savoir un peu plus sur ta façon de faire
• Dans mon attribut WebGet, j'ai mis le schéma d'URI "/clientaccesspolicy.xml". C'est sensible à la casse ce paramètre?
• J'ai oublié un autre détail sur l'étrangeté du phénomène : L'application (cliente et serveur) prise telle quelle, fonctionne bien en HTTP (port 80 ou 4503)...Le fait de la passer en HTTPS (sur le port 4503...Mais j'ai également testé le port HTTPS standard 443) l'empêche de fonctionner correctement tant qu'on ne rajoute pas le binding nécessaire dans IIS.

J'ai lu d'autres article traitant de "comment fonctionnent les composants web de Microsoft"...Le seul point commun entre WCF en self-hosted et IIS, c'est la pile de protocole HTTP implémentée dans HTTP.SYS. Ça voudrait dire que IIS "ouvre le protocole de communication" dans cette pile lorsqu'on crée le binding, alors qu'une appli en self-hosted ne le fait pas automatiquement et ce, uniquement en HTTPS. J'trouve ça vraiment étrange comme explication, mais c'est la seule que je vois à l'heure actuelle.

Si ça vient bien de là, comment peut-on faire pour "réaliser cette ouverture de protocole dans la pile HTTP Windows" sans passer par IIS?