Evolution de l'application fonctionnelle des rencontres Visual Basic

Paru le 19 janvier 2005 | Dernière mise à jour le 01 août 2005

Par Eric Vernié

Dernières mises à jour : nouvelle étape

Quatrième épisode, cinquième version de l'application, 7 mois de développement, ça y est. Eric passe à Visual Basic 2005 beta 2.

La démarche que je vais adopter dans cette article est :

• Convertir le programme de 2003 vers 2005 et le faire fonctionner tout simplement
• D’utiliser les nouveautés à la fois du Framework 2.0 et de Visual Basic 2005
• De profiter du portage de l’application vers 2005, pour faire une revue de code en termes de sécurité. Dans chaque module où une nouvelle fonctionnalité est utilisée, j’ai pu réétudier le code et j’ai découvert des trous potentiels. Oui, oui, il y en a !!!. Ils ne sont d’ailleurs pas dus au Framework 1.1 mais bien à mon code.

C'est décidement mieux que le dernier tome d'Harry Potter :-). Pour lire la suite et découvrir le code, cliquez ici.

Haut de page

Dans l'épisode précédent ...

Dans ce troisième épisode, nous allons essayer de répondre aux questions « sécurité » que nous nous posions à la fin de l’article précédent.

Je résume : si je fais une rapide revue de code de la sécurité de mon application, voici ce que je peux constater.

Regardons les différentes couches de l’application.

• L’interface graphique.

  La fenêtre d’authentification stocke dans une chaîne de caractères le mot de passe. Ce n’est pas l’optimum en termes de sécurité. En effet, le Garbage Collector lorsqu’il compacte la mémoire ne fait pas un ZeroMemory(). En d’autres termes si l’emplacement mémoire ou se trouve le mot de passe n’est pas utilisé tout de suite, il est toujours visible. Un dump pourrait permettre à un hacker de le retrouver.
  Comment faire pour protéger réellement mon mot de passe ?

• La fabrique de classe.

  Ma fabrique de classe ne vérifie pas les assemblies chargées. Une personne malicieuse pourrait donc utiliser ses propres assemblies pour se connecter aux systèmes.
  **Comment faire pour que les assemblies chargées soient dignes de confiance ?**Ma fabrique de classe est utilisable par tous.
  Comment la protéger et ne restreindre son emploi qu’à mon application ?

• Accès aux données via les objets de sécurité.

  La chaîne de connexion est en claire dans le fichier de configuration.
  Comment faire pour la crypter ?

• Du fait que nous tournons sous .NET tout le code source (algorithme, chaînes de caractères, etc.) sont très facilement visibles à l’aide d’utilitaire comme ildasm ou même mieux encore comme reflector.
  Comment éviter alors que l’on fasse du reverse engeniering sur nos assemblies ?

Pour lire et tester le nouvel applicatif v0.0.0.3, rendez-vous ci-dessous!

Haut de page

Retour sur l'épisode 2

Nous en sommes à la troisième version de cette application (v002). Cette version implémente les fonctions de sécurité (rôles et authentification) et c'est Eric qui vous le dit :

"Ce second article n’est pas un article sur la sécurité dans .NET, ne vous attendez donc pas à avoir une explication détaillée des mécanismes de sécurité. Si vous souhaitez plus d’informations, je vous invite à aller sur le site MSDN français ou américain.

Dans mon précèdent article, nous avons commencé à mettre en place un mécanisme de sécurité de gestion de l’authentification et des autorisations.

Un utilisateur, s’authentifie et en fonction du ou des rôles dont il fait partie, il a accès à des ressources ou pas. Nous avions utilisé pour cela des classes du framework .NET (GenericIdentity et GenericPrincipal), qui nous permettaient d’affecter à la thread courante l’utilisateur connecté à l’application et les rôles dont il faisaient partie.

Néanmoins le système de sécurité n’était pas complet et je ne savais pas encore comment nous allions l’implémenter. J’ai donc utilisé un système dit « bouchon » et le modèle de conception « fabrique de classe » pour minimiser l’impact du développement lors de l’intégration avec le vrai système de sécurité.

Nous avions alors un certain nombre de questions en suspend :
Comment implémenter l’autorité d’authentification ?
Comment implémenter la gestion des rôles ?

Dans ce second article, nous allons essayer de répondre à ces questions et on pourra ensemble vérifier les bienfaits de la Fabrique de classe mais également ses contraintes."

Télécharger l'article complet d'Eric et la démonstration fonctionnelle de la v 0.0.0.2!

Haut de page

La démarche d'Eric

"Lors des rencontres Visual Basic .NET, je vous ai présenté une application fonctionnelle, qui permettait d’afficher très simplement des données dans différents formulaires.
Mon idée de départ, était de vous montrer qu’il était possible avec Visual Basic .NET de créer des applications avec un « Look and Feel » à la Windows XP, d’utiliser de nouveaux contrôles et propriétés graphiques qui permettent d’ajouter des fonctionnalités d’ancrages de « docking » de partage de fenêtre et d’effet de fondu enchaîné avec très peu de lignes de codes.
Il s'agissait également de monter que, sans penser Architecture et Programmation Orientée Objet, il était relativement simple de concevoir une application de type MDI (Multiple Document Interface) client-serveur, alimentant des formulaires, par des données provenant d’une base de données JET (Access).

Pour des raisons de simplicité de développement, certains de ces formulaires ont été construits à l’aide de l’assistant d’accès aux données. Néanmoins, aujourd’hui, nous sommes tous à nous accorder, que cet assistant de création de formulaire, présente l’inconvénient majeur de lier très fortement un type de fournisseur d’accès aux données, au formulaire proprement dit. Si demain je dois changer de base de données, je suis obligé de modifier tous mes formulaires en fonction de la nouvelle base de données. Ce type de construction très monolithique, n’est pas optimale dans un contexte où l’agilité d’une entreprise devient primordiale, le changement devenant la règle.

Mon intention est donc de faire évoluer tous les 2 ou 3 mois l’application fonctionnelle MDI, en ajoutant des fonctionnalités, et en la réarchitecturant progressivement afin de bénéficier des dernières innovations ou approches éprouvées par le marché, et en suivant les principes du modèle en couches préconisés. Mon intention, n’est pas de faire l’application ultime en terme d’architecture, mais de vous présenter une autre manière de développer des applications (qui à terme deviendront facilement plus évolutives); de vous présenter comment on utilise les modèles de conceptions (Design pattern) qui nous faciliteront le développement."

Haut de page

Les objectifs

Les objectifs de cette démonstration sont ambitieux et ne pourront se faire qu’au fil de l’eau Voici ce que je vous propose comme menu.

Ajouter des fonctionnalités telles que :

• la gestion des commandes
• la gestion des employés,...
• l'impression
• Utiliser et tirer profit du modèle en couches (n-tiers)
• Utiliser des modèles de conceptions « les fameux design patterns », pour rendre l’application plus évolutive (oPouvoir changer d’une base de données sans impact).
• Proposer une interface graphique, qui soit multi langage
• Faire évoluer l’application vers Visual Basic 2005, lorsqu’il sera disponible ;-)
• D’autres plats qui viendront sans doute en cours de route

Haut de page

Définition fonctionnelle

Tous les développements commencent toujours par un recueil des besoins qui aboutit à une définition fonctionnelle.
Comme vous avez pu le constater, dans la version présentée au Tour VB, l’application s’appuie sur la fameuse base de données Northwind.mdb (Access), qui propose une gestion très simplifiée de vente de produits alimentaires.
Ce que je me propose de faire dans cet exercice, c’est de porter certaines fonctionnalités sur la plate-forme .NET.

Haut de page

Téléchargements

• Document de référence v0004 : Architecture de Trade Northwind
• Application Trade Northwind v0004
• Document de référence v0003 : Architecture de Trade Northwind
• Application Trade Northwind v0003
• Document de référence v0002 : Architecture de Trade Northwind
• Application Trade Northwind v0002
• Document de référence v0001 : Architecture de Trade Northwind
• Application Trade Northwind v0001

Eric Vernié
Eric rencontre les développeurs pour leur faire partager sa passion pour le développement autour des technologies .NET. Il s’occupe également de préparer certain contenu pour des séminaires MSDN et bien entendu pour les DevDays.

Haut de page