Comment proposer une alternative à FTP sous Windows 2003 ? Aujourd'hui, j'ai trouvé trois grandes directions de recherche

SSH + sFTP

BITS

WebDAV + SSL

SSH sous Windows : je n'ai pas épuisé le sujet, mais je n'ai pas trouvé d'implémentation standard, simple de mise en oeuvre, et stable sous Windows 2003. La piste la plus prometteuse pour le moment est un portage Win32 de OpenSSH (http://sourceforge.net/projects/sshwindows), mais le forum et la liste des bugs sont dissuasifs : pas d'activité depuis longtemps, et des problèmes récurrents de stabilité.

BITS : l'implémentation est robuste et l'intégration serveur est bonne, il manque encore un client disponible pour mes utilisateurs. Pour le moment on trouve un utilitaire en ligne de commande pour XP, et quelques wrappers .Net pour la manipulation des jobs, mais il reste quelques ennuyeux problèmes de sécurité (notamment comment protéger un login et un password dans l'application cliente). Exit donc pour quelque temps.

WebDAV + SSL : plus intéressant, puisque la couche de sécurité est robuste et qu'un client WebDav est intégré à l'explorateur Windows. C'est cette solution que je retiens pour le moment. Il reste encore quelques écueils à surmonter, principalement côté serveur. En deux mots, je me refuse à utiliser WebDAV sans SSL.

Ma roadmap :

1/ Installation de  WebDAV

Simple, WebDAV est planqué dans l'install de Windows

2/ Création d'un AppPool avec un compte spécifique. Ce compte est destiné à limiter les privilèges des sites manipulant WebDAV

3/ Création d'une zone disque et d'un site web destiné aux transferts

4/ Pose de SSL sur le site.

cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings ":443:<host header>"

cscript.exe adsutil.vbs set /w3svc/<site identifier>/AccessSSL TRUE

Voilà, SSL est posé et seul SSL est utilisable.

Vista est sur le point de sortir, alors esayons d'y voir clair en matière de développement. Malgré tout ce que vous avez pu entendre ou lire ces derniers mois, Vista est beaucoup plus qu'un relookage de Windows XP. Pour vous en convaincre, allez donc lire http://en.wikipedia.org/wiki/Windows_Vista, qui déroule en une seule page concise la liste des nouveautés.

Dans l'ensemble, les applications Windows conçues pour XP tournent directement sur Vista. Dans l'ensemble seulement, puisque les nombreuses modifications liées à la sécurité bloquent certaines fonctionnalités des programmes. Les applications .Net sont bien évidemment peu concernées par ces modifications, puisqu'elles reposent sur un framework conçu et adapté par Microsoft. Pour les applications Win32 classiques tout dépend de ce que fait votre programme, et plus vous tentiez de prendre la main sur le fonctionnement normal de l'OS plus vous risquez de mauvaises surprises en exécution dans un environnement normal sous Vista (vous pouvez bien sûr détacher les ceintures de sécurité et désactiver un certain nombre de protections, mais c'est à vos risques et périls).

Visual Studio est l'une des applications les plus intrusives sur le système d'exploitation : intégration d'un débogueur capable de prendre la main dans tous les environnements, de JavaScript à VB6 en passant pas SQL Server et .Net, accès aux services, déboguage à distance, développement de drivers, etc. En pratique, Visual Studio (2002, 2003, et 2005) ne fonctionne pas complètement sous Vista : en tant qu'éditeur de code et environnement de compilation il donne satisfaction, mais certaines fonctionnalités avancées seront vraisemblablement bloquées par le système d'exploitation.

Quelles sont les possibilités offertes au développeur pour se prémunir contre les mauvaises surprises ? Pour Visual Studio 2005, le SP1 devrait combler la plupart des lacunes, et les éventuels bugs résiduels seront corrigés au fur et à mesure de leur découverte. Pour Visual Studio 2003 le problème est plus délicat, et pour le moment Microsoft ne supporte pas Visual Studio 2003 sous Vista, même si la plupart des scénarios d'utilisation fonctionnent. Il reste alors deux possibilités. Soit faire tourner Visual Studio 2003 sous Windows XP (éventuellement dans une VPC) ou Windows 2003, soit utiliser MSBuild pour éditer et compiler des projets .Net 1.1.

Cette possibilité n'est pas offerte nativement par MSBuild, mais vous trouverez sur CodePlex la solution (http://www.codeplex.com/Wiki/View.aspx?ProjectName). MSBee, puisque c'est son nom, est un add-on à MSBuild permettant de faire de la compilation .Net 1.1 depuis MSBuild, et donc d'utiliser le même outil pour .Net 1, 2 et 3 dans vos développements.

Vous avez sans doute besoin lors de vos développement de mettre en place du SSL ou des certificats. Les outils disponibles sous Windows variant d'une version à l'autre et selon les SDKs que vous avez installé, voici une alternative simple.

Le site CACert.org peut vous délivrer automatiquement des certificats. Le bon côté : ils sont gratuits, et leur obtention est immédiate pour peu que vous disposiez d'un email sur le domaine qui vous intéresse. Le mauvais côté : étant automatiquement générés sur simple demande, l'autorité de certification qui les délivre n'est pas intégrée dans les certificats racine des machines des utilisateurs, et leur utilisation déclenche systématiquement le filtre anti-phishing d'IE7.

Si vous désirez les utiliser, voici les prérequis :

• Posséder un nom de domaine (exemple.com)
• Pouvoir générer une demande de certificat pour le domaine
  • Par exemple via l'assistant intégré à IIS
• Pouvoir récupérer les mails envoyés à admin@exemple.com ou postmaster@exemple.com
  • CACert génère des mails de vérification vers ces adresses

Il vous suffit ensuite de vous inscrire sur le site de CACert, puis d'inscrire votre domaine, et enfin de transmettre une requête de certificat concernant votre site.