Je poursuis ma série d’articles sur WCF en vous présentant cette fois-ci le mode de communication Streamé. Histoire d’aller un petit peu plus loin, j’ai protégé le service de manière personnalisée et utilisé un binding très courant : BasicHttpBinding.
L'objectif avoué de cet article est de mettre en place un mode de communication Streamé entre un client et un service afin de transférer des fichiers de taille importante. Pourquoi utiliser le mode Streamé dans ce cas bien précis ? Simplement dans un souci d'alléger quelque peu la mémoire et ne pas charger l'ensemble des données d'un bloc, ce afin d'améliorer la scalabilité des applications échangeant des messages d'une taille conséquente. Enfin pourquoi réaliser cet article sur le Binding « BasicHttpBinding » ? Simplement pour se conformer à la norme WS-I Basic Profile 1.1, afin de garder une certaine ouverture avec les technologies clientes un peu plus ancienne et aussi parce que je n'avais pas besoin des fonctionnalités WS-* précisément.
La lecture de cet article suppose quelques connaissances de base sur Windows Communication Foundation ainsi qu'une bonne connaissance du langage C#.
L'exemple a été développé en C# avec Visual Studio Team System 2008, Framework 3.5 sur Windows Vista Ultimate US.
WCF propose de base deux modes pour transférer des messages entre un client et un service :
Le paramétrage peut se réaliser de manière impérative sur le Binding concerné ou bien de manière déclarative. Par exemple :
Ce petit exemple permet fonctionnellement de choisir un fichier en local via une application Windows Forms très simple, d'en déduire son Type Mime, de renseigner quelques attributs (taille, nom de fichier) et de constituer un Message dans le sens WCF du terme qui sera envoyé en mode Streamé. Voici une copie d'écran de la solution. Nous retrouvons un découpage assez classique :
Vous noterez que le Host est un site Web hébergé sous IIS, port 80.
La Propriété « DataFile » est le Stream qui transitera.
Concrètement et parce que je souhaitais mettre en place une communication Streamée en utilisant un encodage MTOM, j'ai utilisé la notion de Message contenu dans WCF. En d'autres termes, au lieu d'utiliser les habituels attributs « DataContract » (sur la classe) et « DataMember » (sur les propriétés), j'ai utilisé « MessageContract » (sur la classe), « MessageHeader » (sur les propriétés) et « MessageBodyMember » (sur les propriétés).
Le message sera sérialisée sous la forme d'une enveloppe SOAP. Toutes les propriétés marquées « MessageHeader » seront sérialisées dans l'entête de l'enveloppe et tous les propriétés marquées « MessageBodyMember » le seront dans le corps du message. A noter que lors d'un transfert Streamé, seul le corps du message l'est et les entêtes sont elles bufférisées.
Il s'agit d'une interface WCF tout ce qu'il y de plus traditionnelle, marquée avec l'attribut « ServiceContract » et les signatures marquées « OperationContract ».
L'implémentation en elle-même n'a rien de compliqué. La classe implémente l'interface du service WCF. Par contre, elle ne gère pas les problématiques d'Uploads concurrents d'un fichier de même nom, puisque du côté du service, le fichier est enregistré sous le même nom que sur le client. Enfin, je ne me suis pas servi du type MIME envoyé en paramètre dans le header de l'enveloppe SOAP.
Techniquement, il s'est agit de lire dans le flux appelé « DataFile » du message SOAP reçu. Le fait qu'il soit transmis de manière Streamée n'a pas eu de conséquence particulière dans la lecture dudit flux.
Le host utilisé est un host de type Application Web sous IIS. Le service WCF d'Upload est accessible via un fichier à extension « .svc » qui permettra au pipeline WCF de prendre la main. Le fichier svc est lié à la classe métier WCF Upload implémentant le service d'Upload. Par conséquent, ce projet doit référencer à la fois le contrat de données, le contrat de service et l'implémentation du contrat de service.
Enfin, la partie WCF est complètement configurée via le fichier de configuration de l'application (« web.config »). Quelques éléments notables du fichier de configuration :
- Les requêtes HTTP étant limitées à une taille par défaut de 4 Mo, il a fallu les reconfigurer au niveau de la configuration de la Runtime ASP.NET, de la manière suivante :
<system.web>
<httpRuntime maxRequestLength="2097151" />
...
- Le binding « BasicHttpBinding » étant relativement limité (comme beaucoup d'autres bindings d'ailleurs) en terme de taille de données échangées (requête, taille de tableau, taille des chaînes de caractères, etc.), il s'est agit de revoir à la hausse ces quotas en créant une configuration de binding spécifique de la manière suivante :
<basicHttpBinding>
<binding name="NewBinding1" maxBufferSize="334217728"
maxBufferPoolSize="52428800"
maxReceivedMessageSize="334217728"
messageEncoding="Mtom"
transferMode="Streamed">
<readerQuotas maxArrayLength="100000000"/>
<security mode="TransportWithMessageCredential" >
<transport clientCredentialType="Basic" />
</security>
</binding>
</basicHttpBinding>
C'est aussi dans cette configuration de binding que l'on retrouve le paramétrage du flux Streamé (transferMode="Streamed"), ainsi que la définition de l'encodage (messageEncoding="Mtom").
Pour les aspects paramétrage de la sécurisation du service, un paragraphe dédié explique tout cela ci-après.
- La mise à disposition des métadonnées du service sur HTTPS et la propagation des exceptions exactes jusqu'au client via le ServiceBehavior précédemment créé :
<serviceMetadata httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
Il va de soit que le paramétrage « includeExceptionDetailInFaults="true" » n'est pas à reproduire sur un service en exploitation pour des raisons évidentes de confidentialité et de sécurité. C'est mieux quand on l'écrit et maintenant, c'est fait ;-)
L'interface de l'application cliente se présente de la manière suivante :
Comme à mon habitude, il n'y a aucune conception ergonomique dans cette interface. Pour Uploader le fichier, il suffit de cliquer sur « Send » dans le menu, de choisir le fichier à « Uploader » et attendre que le formulaire ne soit plus figé ... Ce comportement est facilement améliorable, mais ce n'était pas l'objet de cet article.
Dans cette partie, j'ai donc utilisé un proxy WCF autogénéré en faisant un simple « Add Service Reference » :
noter que je n'ai pas géré de « CallBack » en fin de tâche de transfert, pour la simple et bonne raison que le binding BasicHttpBinding utilisé n'est pas dual ...
Comme pour le Host, toute la partie configuration WCF est réalisée dans le fichier de configuration de l'application. Il n'y a rien de notable dans ce dernier, on y retrouve dans le désordre, la configuration du binding : MTOM, Streamed, quotas, HTTPS, etc.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<remove name="NewBinding0" />
<binding name="BasicHttpBinding_IUpload" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00"
sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false"
hostNameComparisonMode="StrongWildcard"
maxBufferSize="65536000" maxBufferPoolSize="52428800"
maxReceivedMessageSize="65536000"
messageEncoding="Mtom" textEncoding="utf-8" transferMode="Streamed"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="81920000"
maxArrayLength="16384000" maxBytesPerRead="4096000"
maxNameTableCharCount="16384000" />
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Basic"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://localhost/Sample.Upload.Web/Upload.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IUpload" contract="Proxy.IUpload"
name="BasicHttpBinding_IUpload" />
</client>
</system.serviceModel>
Finalement la seule particularité technique du client vient de mon envie de récupérer le type MIME associé au fichier uploadé pour l'envoyer dans le message. Pour cela, Linq To Objects me paraissait tout à fait approprié pour requêter la base de registre et plus particulièrement la ruche « HKEY_CLASSES_ROOT\ MIME\Database\Content Type » pour récupérer la liste des types Mime avec leur extension comme valeur de clé. J'ai donc créé une requête Linq permettant de construire un dictionnaire de Type mime en clé (String) et d'extension en valeur (String). Voici le code de la méthode pour faire cela et charger le cache une bonne fois pour toute :
private void LoadMimeCache()
{
// Get all Content Type names
String[] s
= Registry.ClassesRoot.OpenSubKey("MIME\\Database\\Content Type").GetSubKeyNames();
RegistryKey rk = Registry.ClassesRoot.OpenSubKey("MIME\\Database\\Content Type");
// Build a dictionary of Content Type / File extension
ExtensionCache = (from c in Registry.ClassesRoot.OpenSubKey("MIME\\Database\\Content Type").GetSubKeyNames()
let extension = rk.OpenSubKey(c.ToString()).GetValue("extension")
where extension != null // Gestion des Content Types sans extension de fichier
select new { ContentType = c.ToString(), Extension = (String)extension })
.ToDictionary(c => c.ContentType, d => d.Extension);
}
Le membre ExtensionCache est un « Dictionary<String, String> ». Ensuite, il me fallait à partir d'une extension de fichier récupérer les types MIME correspondant et récupérer le premier, s'il existait (de manière arbitraire). Voici donc le code utilisé pour cela :
if (openFileDialog1.ShowDialog() == DialogResult.OK)
{
FileInfo f = new FileInfo(openFileDialog1.FileName);
using (Proxy.UploadClient client
= new Proxy.UploadClient("BasicHttpBinding_IUpload"))
{
var kvp = (ExtensionCache.Where(c => c.Value == f.Extension)).ToList();
...
client.UploadFile(
kvp.Count == 0 ? "" : kvp[0].Value,
System.IO.Path.GetFileName(openFileDialog1.FileName),
f.Length,
openFileDialog1.OpenFile()
);
...
}
Vous noterez l'utilisation de la méthode d'extension « Where » chargée de filtrer les objets via une expression lambda. Franchement je vous avoue que plus j'utilise ces syntaxes et plus je deviens accros de part la simplicité d'écriture.
La sécurisation du service WCF fut une partie très intéressante à implémenter du fait que je souhaitais réellement faire quelque chose de personnalisé. Dans un premier temps, il s'est agit de mettre en place HTTPS sur ma machine. Pour cela, j'ai simplement utilisé la possibilité de faire générer un certificat SSL sur ma machine et de l'associer ensuite à l'application Web hébergeant mon service WCF. Je me suis donc servi de la Management Console de IIS afin de générer un certificat « auto-signé » à des fins de test. Une fois ce certificat créé, il m'a suffit d'accéder au site Web par défaut pour y associer ce certificat SSL.
Enfin, mon application Web étant un répertoire virtuel du site par défaut, j'ai ensuite indiqué à IIS de lui appliquer ce certificat.
Bien évidemment, ce certificat n'étant pas vérifié par une autorité compétente, un avertissement sera affiché par les navigateurs devant s'y connecter, ce qui impliquera une gestion particulière lors de l'accès au service WCF par la suite via le proxy qui sera généré.
Il restera ensuite à autoriser « HttpsGetEnable » au niveau des métadonnées du service afin de rendre l'accès possible au WSDL via HTTPS.
Pour plus d'information là-dessus, je vous invite à consulter l'article
suivant.
L'étape suivante a consisté à définir une authentification personnalisée au niveau du service. Pour cela, il suffit de créer une classe héritant de la classe abstraite « UserNamePasswordValidator » et d'implémenter la méthode « Validate ».
public class MyUserNameValidator : UserNamePasswordValidator
{
public override void Validate(string userName, string password)
{
if ( userName == null || password == null )
throw new FaultException("Please provide non empty login and password!");
if (!(userName == "fcolin" && password == "bewise"))
throw new FaultException("Unauthorized access!");
}
}
Il reste maintenant à indiquer au pipeline d'exécution la nouvelle manière de valider l'identifiant et le mot de passe transmis pour authentification. Pour cela, nous procéderons via le fichier de configuration du site en modifiant le behavior associé au service via l'attribut « behaviorConfiguration ». Via, l'attribut « customUserNamePasswordValidatorType » nous pouvons spécifier la classe et l'assembly qui seront chargées de tout cela.
<services>
<service behaviorConfiguration="NewBehavior" name="Sample.Upload.Services.Upload">
<endpoint binding="basicHttpBinding"
bindingConfiguration="NewBinding1"
contract="Sample.Upload.ServiceContracts.IUpload" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="NewBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
<serviceCredentials>
<userNameAuthentication
userNamePasswordValidationMode="Custom"
customUserNamePasswordValidatorType="Sample.Upload.Services.MyUserNameValidator, Sample.Upload.Services"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
J'indique ensuite le type de sécurité souhaité (Message, transport, etc.) au niveau de la configuration du binding :
<security mode="TransportWithMessageCredential" >
<transport clientCredentialType="Basic" />
</security>
« TransportWithMessageCredential » signifie que la sécurisation du message est réalisée par la couche transport (HTTPS) et que les Credentials sont transmis au sein du message en lui-même.
La dernière partie consiste à ce que le client transmette ces informations sur HTTPS. Pour cela, il suffit :
- De changer l'adresse dans le fichier de configuration pour passer en HTTPS dans le EndPoint
- Dans le proxy généré avec Visual Studio 2008 (« Add Service Reference »), il existe une propriété pour cela (la variable « client » étant une instance du proxy généré).
client.ClientCredentials.UserName.UserName = textBox1.Text;
client.ClientCredentials.UserName.Password = textBox2.Text;
Si je n'étais pas passé par ce proxy généré, j'aurais simplement utilisé la propriété « ClientCredentials.UserName » de l'instance du ChannelFactory<Tchannel> utilisé en lieu et place.
Du fait que le certificat SSL utilisé du côté du service est auto-généré, cela pose bien évidemment un souci au niveau du proxy en déclenchant une exception. Pour résoudre cette problématique, il suffit d'utiliser une propriété de la classe statique « ServicePointManager » qui gère la création et la destruction d'instance de ServicePoint. Cette dernière permet de spécifier le comportement de validation du client dès lors qu'il reçoit le certificat du serveur.
System.Net.ServicePointManager.ServerCertificateValidationCallback
= (senderObject, certificate, chain, sslPolicyErrors) => true;