mido@IDN :
Ca devient plus compliqué de filtrer les accès Web des applis elles-mêmes.. Sincèrement, je ne me vois pas entrer dans les règles de sécurité du Framework ! J'ai été y fureter, j'en suis vite ressorti..... Et comme, pour le firewall, l'accès Web est ouvert ou non pour le framework, pas évident d'autoriser une appli qui passe par ce framework et pas une autre qui y passe aussi.. A moins qu'il y ait tout de même des solutions..
Reste toujours la soluce d'utiliser des applis qui n'ont pas besoin du framework, mais ça n'est pas toujours une voie utilisée par certains.. D'ailleurs, ne serait-ce pas là une nouvelle méthode pour "ouvrir" un accès Web pour les applis sans qu'elles ne soient "vues" par le firewall, puisque le framework fait apparemment office de tunnel générique de ce côté là ? Ou alors je n'ai pas bien compris son principe de fonctionnement [:spamafote]..
La réponse est un chouia plus complexe:
Imagine un mille feuilles logiciel. Ton OS en est la base et le système de framework vient de placer à son sommet. En fait, à chaque exécution d'une application .NET (.EXE ou bien Web) celle-ci communique via le framework avec le bas niveau. Par conséquent, les services systèmes sont interprétés et mis à disposition du programme via cet intercalaire logique.
Conséquences: tu as deux modes de fonctionnement distincts.
1) les applications .EXE
Elles fonctionnent comme tout programme dits standards, la seule différence est qu'elles interagissent avec le poste via le framework. Quoi qu'il en soit, tout appel Web vers l'extérieur est tout de même vu par le système comme une tentative de communication. Ainsi, le firewall pourra voir cet essai (qui peut être autorisé ou non).
2) les applications .Web.
Là c'est plus corsé. Ton poste devient "virtuellement" son propre serveur Web. C'est un peu comme si tu hébergeais un serveur internet et que tu l'appelais (de manière logique) via ton application. Schématiquement ton application Web est donc mise à disposition en interne sur le PC, puis est appelée via les pages Html nécessaires. De fait, cette communication appelle l'adresse IP du poste, par conséquent 127.0.01... logique non?
Attention, lorsque l'application est mise à disposition à distance, le véritable code .NET compilé n'est pas téléchargé. Le principe est qu' à chaque appel du poste client, les données transférées sont des pages recodées en HTML. Cela évite notamment la possibilité de bidouiller le véritable code applicatif.
J'espère avoir éclairé tes lumières... mais sache tout de même les points cruciaux suivants:
- une application .NET fait très rarement planter le système. Tout au plus c'est le framework qui crashe... et c'est finalement très rare, la gestion d'erreur étant assez bien foutue.
- Une application .NET n'a pour le moment pour but que de rendre son exécution théoriquement interopérable sur une multitude de plate formes. Au jour d'aujourd'hui il y tous les environnements MS (depuis 95 jusque XP en passant par les versions Pocket, mobile et tablet PC). De fait, une application bien codée pourrait théoriquement être mise en place sur n'importe quel de ces équipements. De plus une version linux existe...
- Une application .NET est bien plus facile à mettre en oeuvre car au final il n'y pas le moindre souci de dll, de déploiement ou de mise à jour. Pas de composant à mettre sur le système via la base de registre et encore moins de redémarrages à faire. On installe, on déploie les assemblys et on lance. Si besoin est une assembly peut être mise à jour, on ferme puis on relance l'appli.. et c'est tout. Au surplus la gestion de versionning est on ne peut plus simple! On peut faire cohabiter toutes les versions envisageables d'un même composant sur un poste donné sans se poser trop de questions. Ca évite notamment des problèmes de rétro compatibilité.
- Dernier point: .NET est en phase de progression énorme sur le marché de part tout ces avantages. Cependant, pour l'utilisateur lambda je ne saurais trop conseiller de ne pas trop s'amuser à jongler entre les versions. La dernière étant toujours théoriquement la meilleure, ne changez rien si ça fonctionne.
.... C'est donc aussi pour ça que le firewall comme Kerio ne "voit" pas forcément de différence lorsqu'une appli qui veut accéder à la Toile passe par le Framework : il s'agit toujours d'autoriser un accès local 127.0.0.1 :/..
