I did not have the chance to take part in the last European TechEd But I found some really funny videos about agile process, continuous integration… Thanks to Roy Osherove

And this is the song about Reflection “Deep Reflection” (Always Roy ):

@Sami: for the DNG symposium will you also prepare some songs

test test test

test du plugin digg

Test de code intégré :

avec manoli et le css C# intégré dans blogs@dng :

public class CessnaFactory : IAirplaneFactory
    {
        public const int SEL = 1;
        public const int MEL = 2;
     
        public virtual IAirplane Create(int t)
        {
            switch(t)
            {
                case SEL:
                    return new CessnaSingleEngine();
                case MEL:
                    return new CessnaMultiEngine();
                default:
                    throw new Exception("Unknown Aircraft Type!");
            }
        }
    }

avec le plugin b2 code highlight (je trouve l’habillage pas terrible mais au moins on a les numéros de ligne) :

Code:

A Brief History of DateTime Follow-up [Anthony Moore]
Thanks all for the feedback on A Brief History of DateTime. Thanks Justin for responding to most of this. I can elaborate on some of the issues raised:

>> (3) Was there any consideration given in the design process around making DateTimeOffset an (immutable) reference type?

We did not really consider this because unless something is going to be of an unpredictable size, there is not much benefit of an immutable reference type over a value type. Also, since we wanted to replace many DateTime scenarios going forward we did not want to have a type that performed significantly differently. Can you clarify why you would prefer this design?

>> If I use DateTimeOffset, I will still need to convert it to DateTime when passing it as a parameter to existing methods. This introduces an opportunity for errors.

This might seem scary, but it should not be as problematic as it might seem. The conversions to DateTime can lose some the display time, but not the absolute point in time. Any existing API that treats the DateTime as an absolute point in time will get the right results. Once that don’t will often be subject to usage problems regardless of whether the input is a DateTime or something converted from DateTimeOffset.

>> As it is, we now filter through all source code searching for DateTime usage. Every instance is flagged as a potential bug (and usually is) needing special review

The need to do this is unfortunate, but I would agree that it is necessary with DateTime. The nice thing about DateTimeOffset is that if you can be in a world where within your own application you are using it and not DateTime, the number of usability problems is significantly reduced. Arithmetic, comparison, display and serialization all default to a behavior that is much more likely to be what it is intended. Conversions to DateTime for legacy APIs still need some checking, but there are fewer mistake opportunities than when passing in a DateTime directly.

>> A better solution is to wrap something like http://www.twinsun.com/tz/tz-link.htm.

A Brief History of DateTime Follow-up [Anthony Moore]
Thanks all for the feedback on A Brief History of DateTime. Thanks Justin for responding to most of this. I can elaborate on some of the issues raised:

>> (3) Was there any consideration given in the design process around making DateTimeOffset an (immutable) reference type?

We did not really consider this because unless something is going to be of an unpredictable size, there is not much benefit of an immutable reference type over a value type. Also, since we wanted to replace many DateTime scenarios going forward we did not want to have a type that performed significantly differently. Can you clarify why you would prefer this design?

>> If I use DateTimeOffset, I will still need to convert it to DateTime when passing it as a parameter to existing methods. This introduces an opportunity for errors.

This might seem scary, but it should not be as problematic as it might seem. The conversions to DateTime can lose some the display time, but not the absolute point in time. Any existing API that treats the DateTime as an absolute point in time will get the right results. Once that don’t will often be subject to usage problems regardless of whether the input is a DateTime or something converted from DateTimeOffset.

>> As it is, we now filter through all source code searching for DateTime usage. Every instance is flagged as a potential bug (and usually is) needing special review

The need to do this is unfortunate, but I would agree that it is necessary with DateTime. The nice thing about DateTimeOffset is that if you can be in a world where within your own application you are using it and not DateTime, the number of usability problems is significantly reduced. Arithmetic, comparison, display and serialization all default to a behavior that is much more likely to be what it is intended. Conversions to DateTime for legacy APIs still need some checking, but there are fewer mistake opportunities than when passing in a DateTime directly.

>> A better solution is to wrap something like http://www.twinsun.com/tz/tz-link.htm.

Sniff, les boutons d’édition ne marchent pas

Customizing the behavior of System.Diagnostics.Debug.Assert [Matt Ellis]
When Inbar posted his refresher on the System.Diagnostics.Debug class, Ron Cain asked an interesting question about Assert in the context of a test harness. Because of this I thought it might be nice to expound on some of the details on exactly how Debug.Assert ends up popping up UI when a failure occurs and what you can do to change this behavior.

We’ll start by discussing what happens when a simple call like Debug.Assert(false) is made. All Debug.Assert does is check the condition and if its value is false (as it is in this case) calls Debug.Fail with String.Empty as the message. When Debug.Fail is called, we iterate over theTrace.Listeners collection and call the Fail method on each listener and then return. The subtle point here is that Debug.Assert doesn’t pop up the assertion failed dialog, but instead some listener in the Trace.Listeners collection does. The listener that does this is called the DefaultTraceListener.

As its name suggests, the DefaultTraceListener is added by default to the Trace.Listeners collection when your application runs. If you want, you can remove this listener either by calling Trace.Listeners.Remove(“Default”) at some point in your app or by using an application configuration file that removes the listener. An example configuration file would look like:

sfdgsdfg

test de gallery d’images

(3 petit pas dans l’Open-Source)

Un petit billet un peu moins technique de d’habitude sur mes premiers pas dans le monde de l’Open-Source.
C’est donc avec insouciance que je lançais à la fin avril hibernate4gwt, petite librairie de niche prenant en charge la cohabitation de deux formidables librairies à fort caractère : Hibernate (sa persistance, sa transparence… et ses proxies !) et GWT (sa simplicité, sa souplesse… et son JavaScript !).

Première surprise : on ne dépose pas un projet comme ça sur SourceForge ! Il faut avant tout en faire la demande, exposer le but de son projet, gentiment, poliment et en anglais.

Ensuite, il faut document, packager, tester. Mine de rien, cela force un peu à organiser son travail, à le formaliser d’avantage que juste un bout de code dans son coin. Au final, j’estime passer près de la moitié du temps total sur une release à ces aspects non directement productifs.

Deuxième enseignement : cela prend du temps, beaucoup de temps. Outre le travail de développement, il faut faire un peu de pub sur les groupes de discussions, surveiller les topics pour trouver ceux que votre librairie peut solutionner, répondre aux questions posées sur le forum du projet, etc…

Troisième enseignement : c’est gratifiant J’avoue que quelques mots d’encouragement, postés à la fin d’un message, un simple « thanks » me remplit de contentement. Le simple fait de savoir que des gens à travers le monde utilisent le fruit de mon labeur, que celui-ci leur évite les soucis que j’ai eu à affronter, me conforte dans l’idée que la démarche est la bonne. Et puis, j’adore lire des messages de gens dont j’ignore la nationalité du prénom

Enfin, il y a la satisfaction de poster une release dont vous êtes fier. La dernière version d’hibernate4gwt commence à ressembler à ce que j’avais en tête il y a quelques mois : transparente et légère. En mode Java 1.4, les services GWT doivent juste hériter de HibernateRemoteService pour fonctionner. Pas d’autre impact sur le code 
J’ai également rajouté le support d’objets du Domaine Java5, la demande à ce sujet étant forte (tout comme l’attente du support natif par GWT) en essayant de rester là aussi le moins intrusif possible (pas de fichier de mapping Dozer, qui d’après les retours d’expérience que j’ai, ressemblent plus à une plaie qu’à une solution).

J’ai encore un peu de pain sur la planche (supprimer les derniers héritages techniques !), mais après les efforts que m’ont demandé la dernière release, je vais faire une petite pause… le temps d’écrire un ou deux articles que j’avais promis à developpez.com (non Ricky, je n’ai pas oublié ;-) ) et de finir « Jonathan Strange et Mr. Norrell », un roman aussi prometteur qu’épais

Stay tuned !

Après un aperçu de Fiddler, voici une présentation de l’outil IE Developer Toolbar.

Nous avons tous été confronté lors du développement d’un site web à une page dont la présentation nous pose problème.

Parfois le problème vient d’une hiérarchie d’éléments CSS altérant la page de manière inexacte, dans d’autres cas il s’agit d'une erreur dans les balises (X)HTML et malgré tous nos efforts ,le navigateur n’est pas capable d’effectuer le rendu de manière correcte.

Pour nous aider (et ce n’est rien de le dire), Microsoft met à notre disposition, et ce gratuitement, un outil nommé « Internet Explorer Developer Toolbar ». Cet outil permet de visionner non seulement de manière unitaire chaque élément d’une page Web mais aussi chaque aspect de celle-ci.

L’installation est aussi simple que celle de Fiddler ;-) Une fois installé, l'outils peut être activé via le menu « View – Explorer Bar – IE Developer Toolbar » ou plus directement par le bouton automatiquement ajouté à IE.

Figure 1 : ouverture de IE Developer Toolbar

Présentation générale

Lors de l’execution, trois panels sont ouvertes. Celle-ci sont, par défaut, positionnées en bas de l’écran.

Figure 2 : Présentation par défaut

Pour l’ouvrir sous forme d’application indépendante, il suffit de cliquer sur le bouton « Unpin » situé à droite de la barre d’outils de IE Toolbar.

Figure 3 : Ouverture sous forme d’application indépendante.

Le panel situé à gauche est composé d’un treeview listant chaque élément de la page. Cet écran nous permet ainsi de mieux comprendre la structure de la page en cours. La sélection d’un élément rempli automatiquement les deux autres panels. Ceux-ci contiennent alors l’ensemble des détails de l’élément tels que les attributs ou les styles.

Présentation des menus

Menu Find

Parce qu’une page peut être très complexe, deux méthodes sont possible pour sélectionner un élément particulier :
- En cliquant directement dessus après avoir choisi l’option « Select élément by click » depuis la barre d’outil ou le menu « Find - Select Elément By Click »
- En recherchant l’élément par son Id, Class ou Name en passant par le menu « Find – Search Elément »
Une fois l’élément sélectionné, il est possible de modifier un des attributs en double cliquant sur l’attribut choisi et ainsi en voir immédiatement le résultat. Vous pouvez même créer un attribut de toute pièce.

Menu Disable

Lorsqu’un problème surgit sur une page, la manière la plus simple de le trouver est parfois de simplifier la page.
Le menu Disable permet de désactiver certaines fonctionnalités du navigateur. Ces fonctionnalités sont :
- Les scripts clients (VB ou JS)
- Le popup blocker d’IE
- L’ensemble des styles CSS

Menu View

Ce menu permet d’afficher des détails concernant la page qui ne sont normalement pas disponibles. Ces options de menu sont :
- Class and ID information : affiche les ID et les classes CSS associés
- Link paths : indique l’URL des liens
- Links reports : ouvre une nouvelle page contenant l’ensemble des liens de la page
- Tab Indexes
- Access Keys
- Source : permet d’afficher le code source de la page
Revenons sur ce dernier menu. Le menu « View –Source » permet d’afficher le code source de la page entière ou bien d’une partie de la page (jusqu’au niveau élément ). Le code source est affiché dans un éditeur propriétaire. Celui-ci propose la coloration syntaxique, la numérotation des lignes, la notion de région dans le code (à l’instar de VS.NET) et le « word wrapping ».

Figure 4 : Page avec le menu Link Paths activé

Menu Outline

Comme les divers éléments d’une page peuvent être imbriqués de manière complexe. Il est donc nécessaire de pouvoir les identifier. Pour cela IE Dev Toolbar nous fournit de nombreuses options pour « souligner » différentes catégories d’éléments :
- Table Cells
- Table
- Div Elements
- Images
- Positioned Objects : sélectionne les éléments selon le mode de positionnement (relative, absolu, fixe, flottant)
- Any Elément : permet de définir sa propre liste d’éléments à surligner.

Figure 5 : page avec les balises DIV surlignées

Menu Picture

Ce menu contient plusieurs options permettant de travailler avec les images incluses dans la page.
- Disable Images
- Show Image Dimensions
- Show Image File Size
- Show Image Paths
- View Alt Text
- View Image Report : ouvre une nouvelle fenêtre affichant l’ensemble des images de la page contenant les informations des autres menus.

Figure 6 : fenêtre View Image Report

Menu Cache

Ce menu propose les options suivantes :
- Clear Browser Cache
- Clear Browser Cache for this domain
- Disable Session Cookies
- Clear Session Cookies
- Clear Cookies for this domain
- View Cookie Information : ouvre un fenêtre listant l’ensemble des cookies du domaine

Menu Tools

Ce menu propose une série d’outils très utile au quotidien :
- Resize : permet d’ajuster le navigateur à des tailles standards mais aussi personnalisées
- Show ruler : permet de mesurer la taille d’un élément
- Show Color Picker : permet d’obtenir la valeur hexadécimale et décimale d’une couleur.

Figure 7 : Outil Show Ruler

Menu Validate

Permet de vérifier que la page respecte les normes W3C (rare sont les pages les respectant). On peut valider :

- HTML
- CSS
- Feed
- Local HTML
- Local CSS

Conclusion

Même si ce projet n’est pas une nouveauté en soi, c’est la première application qui inclus l’ensemble des fonctionnalités généralement dispersées dans plusieurs applications.

Pour le télécharger :

Internet Explorer Developer Toolbar

Cette semaine on va abandonner la popup Windows et voguer vers d'autres scénarios. Historiquement cet article devait même être le premier de la série.

Votre site est accessible depuis un intranet ou bien Internet. Pour les personnes en provenance de l'intranet vous proposez une authentification Windows, donc entièrement transparente avec les réglages usuels des navigateurs.
Pour celles en provenance d'Internet vous souhaitez leur présenter un formulaire d'authentification. Elles devront disposer d'un compte géré par exemple dans une base de données locale à l'application.

Il existe différentes façons de faire les choses, mais je pense que le moyen le plus élégant utilise la technique du 401 détaillée la semaine dernière.

C'est dans le blog de Craig Andera[1] que j'ai rencontré la première solution à ce problème. A cette époque je cherchais une idée de saga de l'été, j'ai donc poursuivi l'idée. Document historique par conséquent!

Créez un projet de test avec deux formulaires.
Le premier est la page d'accueil avec un message de bienvenue:

<form id="form1" runat="server">
<asp:loginname ID="LoginName1" runat="server" />
<div>
Bienvenue dans la saga de l'été!</div>
</form>

Le second est un formulaire d'authentification:

<form id="form1" runat="server">
    <asp:label ID="ErrorMessageLabel" runat="server" Text="">
</asp:label>
    <div>
        <asp:label ID="Label1" runat="server" 
Text="Identifiant"></asp:label>
        <asp:textbox ID="UsernameTextBox" 
runat="server"></asp:textbox>
        <br />
        <asp:label ID="Label2" runat="server" 
Text="Mot de passe"></asp:label>
        <asp:textbox ID="PasswordTextBox" 
runat="server"></asp:textbox>
        <br />
        <br />
        <asp:checkbox ID="CheckBox1" runat="server" 
Text="Utiliser mes autorisations réseau" />
        <br />
        <br />
        <asp:button ID="Button1" runat="server" 
Text="Connexion" /></div>
</form>

Rien que du classique, remarquez juste la case à cocher. Nous complèterons son code behind plus loin.

Placez le projet dans un répertoire virtuel et positionnez les paramètres de sécurité de IIS en sélectionnant accès anonyme ET authentification Windows.

Complétez le fichier de configuration du site en authentification Forms.

<authentication mode="Forms" >
    <forms loginUrl="login.aspx">
    </forms>
</authentication>
<authorization>
    <deny users="?"/>
</authorization>

Si vous avez été attentif, vous savez que le serveur Web ne tentera pas d'authentifier les utilisateurs tant qu'il n'a pas reçu un 401 puisque l'accès anonyme est coché. A nous de choisir le moment le plus astucieux pour le faire.

Que se passe-t-il?

Votre site est un succès, un sympathique utilisateur se présente déjà. Il n'est pas encore authentifié et se voit donc présenter le formulaire Login.aspx.

S'ils disposent d'un compte local il lui suffit de saisir son identifiant et un mot de passe puis cliquer sur le bouton de connexion.

Il est temps de regarder un peu le code behind. Le code du gestionnaire Page_Load est le suivant:

if (IsPostBack)
{
    string authenticatedUser = null;
    if (CheckBox1.Checked) 
    {
        // utilise les autorisations d'authentification 
fournies par le réseau

        string user = Request.ServerVariables["LOGON_USER"];
        if (user.Length == 0)
        {
            // pas encore authentifié
            Response.StatusCode = 401;
            Response.StatusDescription = "Désolé!";
            Response.End();
        }
        else
        {
            // déjà authentifié
            authenticatedUser = user;
        }
    }
    else
    {
        // utilise le login/mot de passe fourni
        if (IsPasswordOK(UsernameTextBox.Text, 
PasswordTextBox.Text))
        {
            authenticatedUser = UsernameTextBox.Text;
        }
    }
    if (authenticatedUser != 
null)
    {
        // l'authentification a réussie
        FormsAuthentication.RedirectFromLoginPage(
authenticatedUser, false);
    }
    else
    {
        ErrorMessageLabel.Text = 
"L'identification a échouée, veuillez recommencer.";
    }
}

Dans ce cas la méthode IsPasswordOK est exécutée. Cette méthode va simplement vérifier si le compte avec ce mot de passe existe bien en base. Dans ce cas l'utilisateur chanceux est authentifié et se voit dirigé vers la page d'accueil.

Le cas intéressant est celui où l'on a coché la CheckBox. Alors les éventuelles saisies sont ignorées. Une réponse avec un code 401 est retournée au serveur Web qui tente alors d'authentifier l'utilisateur.

Le mode d'authentification sélectionné est Windows. IE accepte automatiquement les autorisations fournies par le serveur et est lui aussi dirigé vers la page d'accueil. Si vous utilisez Firefox il faudra s'authentifier avec la popup. Mais on peut aussi lui demander de fonctionner comme son concurrent moyennant un petit paramétrage [2].

Notez un point, l'utilisateur a toujours la possibilité de sortir l'intranet de sa zone de confiance (menu Options Internet/Securité). Dans ce cas la popup d'authentification s'ouvrira quoi qu'il arrive.

On peut perfectionner un peu les choses. Si par exemple l'utilisateur saisie ses identifiants et coche la case. Alors on commence par tenter une authentification locale et si elle échoue on lance le 401.

Il existe d'autres approches possibles avec leurs qualités et leurs défauts. Celle de Dimitri Glazkov par exemple [3] qui fait usage d'un fichier "mulet". Je ne suis pas vraiment fan de cette solution qui impose des contraintes de déploiement, mais pourquoi pas?

Note d'ailleurs

Vous souvenez vous du clip avec les grenouilles qui chantent et qui dansent qui faisait les beaux jours des interludes de la deuxième chaîne lorsqu'il y avait un problème technique?

Everybody's got to live together
All the people got to understand
So, love your neighbour
Like you love your brother
Come on and join the band

La cure de jouvence est ici:

http://www.laderniere.info/Blog/index.php/2007/04/22/35-butterfly-ball-grenouille-et

Bibliographie

[1] Blog de Craig Andera:
http://www.pluralsight.com/blogs/craig/archive/2004/07/24/1699.aspx

[2] Authentification Windows automatique dans Firefox. Lisez aussi les commentaires:
http://ackbarr.xoops.org/archives/2005/03/31/integrated-windows-authentication-in-firefox

[3] Autre solution de Dimitri Glazkov:
http://glazkov.com/blog/credentials-screening/

[4] Un article sur les méthodes d'authentification avec IIS:
http://www.4guysfromrolla.com/webtech/020201-1.shtml

[5] Un très intéressant article de référence sur les configurations SSO d'ASP où divers scénarios sont étudiés:

Parmi les grandes évidences, un site web consomme de la bande passante et celle-ci bien baisse de manière constante, elle n'est pas infinie. Bien entendu il existe de nombreuses techniques pour en réduire son usage : compression, cache et meilleure gestion des appels serveurs en sont un exemple.
Malheureusement nous ne sommes pas toujours maitre de l'utilisation de la bande passante, particulièrement si l'on utilise des composants tiers ou la "technologie" AJAX.
Mais alors comment vérifier cela ? C'est là qu'un analyseur réseau tel que Fiddler devient indispensable.

A quoi sert Fiddler

Fiddler une fois installé sur un ordinateur client permet d'analyser exactement ce que contiennent (ou pas) les requêtes HTTP envoyées par le client au travers du réseau. Il capture les détails de chaque requête, postback, requête AJAX, ...
Il ne faut pas oublier que le chargement d'une page ne se fait pas en une seule requête mais en plusieurs parties (contenu html, images, fichiers JavaScript et CSS,...)
Fiddler permet de vérifier la manière dont chaque requête est gérée.
Fiddler trouve tout son intérêt avec les requêtes AJAX. En effet les requêtes AJAX étant invisibles à l'utilisateur, sans un outil comme Fiddler il est quasiment impossible de tracer les données échangées entre le serveur et le client.

Première utilisation

Le téléchargement et l’installation sont des plus simple. Une fois installé un bouton est disponible dans la barre de commandes d’Internet Explorer.

Figure1

Pour information, Fiddler est compatible avec IE et Firefox. Pour ce dernier il faut configurer son proxy sur l’adresse 127.0.0.1 et le port 8888 (merci à Améthyste pour cette info ;-) )
Un fois lancé, et sa fabuleuse interface apparue ;-) le trafic réseau est immédiatement loggé.

Figure 2

Sur la partie gauche on y retrouve la liste des « Web Sessions »
Un clic sur un des items de cette liste affiche l’écran « performance statistics ». A noter qu’il est possible de sélectionner plusieurs lignes afin d’agréger les résultats.
Cet écran permet de connaitre combien de bytes ont été envoyés et reçus et combien de temps cela a pris. Fiddler fournit une information assez originale puisqu’il est possible de connaitre le temps que cette même session aurait pris à d’autres endroits du monde et avec d’autres types de connexions.
Le lien « Show Chart » permet d’afficher un camembert

Figure 3

Lorsque qu’au moins une ligne est sélectionnée de nombreuses options sont proposées. On y retrouve la possibilité de :
- supprimer un, plusieurs ou tous les éléments.
- Marquer un ou plusieurs éléments avec une couleur différente.
- Enregistrer le ou les Requêtes/Réponses sous différent formats.
- Enregistrer la session sous plusieurs formats, ce qui inclus entres autres le format webtest de VS2005.

Un double clic sur une ligne affiche l’écran « Session Inspector ». Ce dernier ne compose de deux sous écrans. Celui du haut pour la requête et le celui du bas pour la réponse.

Figure 4

Pour chaque écran, on retrouve plusieurs onglets fournissant toutes les informations utiles :
- Header
- Text
- Forms
- Hexadecimal
- Authorization
- Raw
- XML

L’écran du bas (réponse) dispose en plus des onglets :
- Privacy
- Caching
- Image view

Analyse des événements

Chaque ligne de requête est composé de neuf colonnes pouvant être déplacées à souhait.

Figure 5

Les colonnes « Host » et « URL » contiennent les détails concernant le serveur, path et fichier de l’élément demandé. « Result » indique le code retourné par le serveur (ex : 200 - réponse OK et 404 - ressource non trouvée). « Body » contient la taille de la réponse. Cette valeur peut être égale à 0 si l’élément étant présent en cache dans le navigateur.
La colonne « Caching » indique le type de cache éventuellement appliqué à l’élément. « Content Type » donne le format du contenu associé à cette requête comme « text/html », « image/jpeg », « application/x-javascript », etc. On retrouve la valeur de ces deux colonnes dans l’écran « Session Inspector - Response»

Debug avec Fiddler

Une des fonctionnalités vraiment intéressante est la possibilité de créer des requêtes http à la volée. Pour cela il faut choisir l’onglet situé en haut à droite « Request Builder ».

Figure 6

Bien qu’il soit possible de tout saisir à la main, il est plus simple sélectionner une requête existante dans la liste de gauche en la faisant glisser sur la partie de droite. Ensuite libre à vous de modifier son contenu et d’exécuter la requête.

Une autre fonctionnalité est la possibilité de place un point d’arrêt avant que la requête soit envoyée au serveur ou juste après la réception de la réponse. Cela permet de modifier la requête après qu’elle soit générée mais avant son envoi au serveur.

Personnalisation de Fiddler

Pour tous ceux qui souhaite encore plus de fonctionnalités dans Fiddler, il est possible de le personnaliser afin de l’adapter à ses désidératas. Il est par exemple de possible de modifier les couleurs des éléments de la « Session List »
Pour « modifier » Fiddler, il faut utiliser le menu « Rules – Customize Rules… ». Cela ouvre le fichier CustomRules.js. Je vous laisse le découvrir mais pour information, il existe un éditeur spécialisé.

Resources en ligne

Le site Fiddler (http://www.fiddler2.com) met à disposition de nombreux outils et ressources. En voici une courte liste:
• Vidéos de démonstration: http://www.fiddlertool.com/fiddler/help/video/default.asp
• Editeur FiddlerScript: http://www.fiddlertool.com/fiddler/fse.asp
• FiddlerScript Cookbook : http://www.fiddlertool.com/fiddler/dev/scriptsamples.asp
• Etendre Fiddler avec du code personnalisé: http://www.fiddlertool.com/fiddler/dev/
• Fiddler FAQ: http://www.fiddler2.com/fiddler2/faq.asp
• Fiddler sur MSDN: http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/IE_Fiddler2.asp
• Fiddler Blog: http://insidehttp.blogspot.com
• Fiddler Forum: http://groups.msn.com/HTTPFiddler/

Lors des rencontres GWT, j’ai montré un exemple d’intégration EJB 3 GWT basé sur le nouveau design RPC de la version 1.4. Dans les jours qui ont suivi, j’ai reçu énormément de mails me demandant le code source de cette démo.

Il y a très peu, voire quasiment pas (à ma connaissance) d’information publiée sur le Web à ce sujet. Alors que Spring est présenté comme modèle d’intégration RPC, il faut avouer que EJB 3 souffre d’un manque de reconnaissance du Framework GWT. Et pour cause, EJB 3 ce sont les annotations, les génériques, le JDK 5 et toutes les fonctionnalités non (encore) supportées par le compilateur GWT.

Du coup, j’ai essayé de prendre le meilleur des deux mondes en proposant un mariage qui soit le plus doux possible et surtout le plus pérenne en attendant les prochaines évolutions du Framework.

Dans son nouveau mode d’extensibilité, RPC propose de tirer partie de la reflection et de l’invocation dynamique de méthode. GWT passe en paramètre la méthode et les paramètres invoqués par le client à une servlet chargée de déléguer l’appel à un conteneur EJB. Seule contrainte, la cible de l’invocation doit être un objet dérivant de l’interface cliente (de type RemoteService). J’ai donc dû adapter un peu le principe, lorsque la servlet reçoit l’invocation cliente elle extrait la signature de la méthode et la compare de manière symétrique aux méthodes contenues dans un proxy EJB récupéré préalablement via un lookup JNDI. Je me sers du nom logique paramétré dans le fichier de module comme binding JNDI (ce nom doit correspondre au nom de l’EJB ). Voici le code, je laisse les puristes comprendre précisément pourquoi il m’a fallu écrire la méthode methodEquals() plutôt qu’effectuer l’invocation directement grâce à rpcRequest.getMethod().

package com.myapplication.server;

import java.lang.reflect.Method;
import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.servlet.http.HttpServletRequest;

import com.google.gwt.user.client.rpc.InvocationException;
import com.google.gwt.user.client.rpc.SerializationException;
import com.google.gwt.user.server.rpc.RPC;
import com.google.gwt.user.server.rpc.RPCRequest;
import com.google.gwt.user.server.rpc.RemoteServiceServlet;

public class EJB3ProxyServlet extends RemoteServiceServlet {

public boolean equalsMethod(Method m1, Method m2) {
        // test the method name
        if (!m1.getName().equals(m2.getName())) {
                            return false;
        }

	if (!m1.getReturnType().equals(m2.getReturnType()))
		return false;

	Class[] params1 = m1.getParameterTypes();
	Class[] params2 = m2.getParameterTypes();
	if (params1.length == params2.length) {
		for (int i = 0; i < params1.length; i++) {
			if (params1[i] != params2[i])
				return false;
		}
		return true;
	}
	return false;
}

public String processCall(String payload) throws SerializationException {
	try {
	Object obj = null;
	InitialContext ctx;
	RPCRequest rpcRequest = null;
	try {

	 Hashtable env = new Hashtable();
	 env.put(Context.INITIAL_CONTEXT_FACTORY,
	      "org.jnp.interfaces.NamingContextFactory");
	 env.put(Context.PROVIDER_URL, "localhost");
	 env.put(Context.URL_PKG_PREFIXES,
		"org.jboss.naming:org.jnp.interfaces");
 	 ctx = new InitialContext(env);
	 // Récupère le nom de l'EJB à partir de l'URL du service RPC
	 String[] path = 
                        getThreadLocalRequest().getServletPath() 
				.split("/");
        // Il préférable de faire des appels locaux EJB en mode GWT RPC
	obj = ctx.lookup("EAR Name" + path[path.length - 1]
				+ "/local");
	HttpServletRequest mod = this.getThreadLocalRequest();
	rpcRequest = RPC.decodeRequest(payload, obj.getClass());
		
        // Cherche la méthode en question dans le proxy EJB  
	for (Method m : obj.getClass().getMethods()) {
		  if (equalsMethod(rpcRequest.getMethod(), m)) {
		   return RPC.invokeAndEncodeResponse(obj, m, rpcRequest
					.getParameters());
	   	  }
	}
   } catch (NamingException e) {
		// Gestion d'erreur minimaliste				
   }

   throw new InvocationException("Method not found");

} catch (InvocationException ex) {
	return RPC.encodeResponseForFailure(null, ex);
}

}

Ce proxy permettra de ne plus avoir à coder systématiquement les délégations et vous fera économiser parfois plusieurs milliers de lignes. Il suffit de spécifier dans le fichier module.xml la servlet EJB3ProxyServlet de la manière suivante :

<servlet path="/MySessionBean" 
      class="com.myapplication.server.EJB3ProxyServlet"/>

Le code client lui, ne bouge pas, par rapport à un service RPC classique.

Vous n’avez plus aucune raison de ne pas utiliser les EJB 3 avec GWT…

MAJ : le code à été modifié pour prendre en compte les remarques de Joan.

Cette semaine on va revenir sur la fameuse popup d'authentification Windows, mais le scénario est résolu autrement.

Pour me simplifier la vie j'appellerai la technique présentée la 401, vous verrez vite pourquoi. Je vais passer pas mal de temps à la détailler car elle est la base de la résolution d'autres scénarios d'authentification qui feront l'objet d'un autre article. En plus elle vous apprendra pas mal de choses sur les coulisses d'une authentification http.

Cet article doit beaucoup à Nicolas Frelat qui a été plus malin que moi et a trouvé le truc pour mettre en œuvre la 401 dans ce scénario.

Fiddler

Dans tous les cas cet article est largement redevable d'un outil: Fiddler. J'ai volontairement détaillé sa genèse pour vous inciter à installer le produit et refaire par vous même les exemples cités.

Fiddler est un outil proposé gratuitement par Microsoft [1]. Il s'agit d'un proxy qui s'installe entre votre serveur Web et votre navigateur et intercepte le traffic HTTP(S) que vous pouvez analyser ensuite.

Si des mots comme "s'installe entre votre serveur Web et votre navigateur" vous rendent nerveux parce que votre administrateur Web est un psychopathe traqué par l'Association Mondiale de Psychiatrie, rassurez vous, l'installation a lieu sur votre poste et tout est automatique. Il suffit de lancer Fiddler depuis la barre d'outil (une jolie image avec un violon (fiddle en anglais) s'affiche brièvement) et la fenêtre principale de Fiddler apparaît.

Fiddler est compatible avec tout navigateur. Il est possible de l'étendre depuis tout langage .NET ou de créer des règles. Certains ne s'en sont pas privés et on peut télécharger pas mal d'addons.

L'écran principal est organisé en 3 parties:

La zone de gauche affiche toutes les sessions qui ont été interceptées. Vous constaterez que l'ouverture d'une page d'apparence simple peut être fort complexe, essayez pour voir la page d'accueil de Google.

Les deux zones de droite représentent la requête (en haut) et la réponse du serveur (en bas). Les deux onglets les plus importants sont Headers et TextView. Le premier affiche le contenu de l'entête HTTP, le second le message brut reçu/envoyé. La fenêtre Raw affiche le message http reçu, donc une concaténation des deux fenêtres.

Je vais en rester là, mais visitez les références [2] et [4] ainsi que le site officiel pour avoir plus d'informations. La référence [2] vous indiquera comment utiliser Fiddler avec IE 7, il y a une particularité.

La 401

Beaucoup de choses vont tourner autour du protocole HTTP 1.1 définit dans la RFC 2616 [3]. Je ne vais pas jusqu'à dire que le document vous tiendra en éveil, mais il n'est pas inutile d'aller y jeter un œil et souvenez vous que "user agent" désigne pour nous un navigateur.

Notre voyage démarre chez IIS.
Vous savez certainement que l'on peut contrôler l'authentification depuis l'onglet Sécurité de Répertoire.
Les 5 modes d'authentification proposés sont:

1. Connexion anonyme
2. Authentification Digest
3. Authentification de Base
4. Authentification intégrée Windows
5. Passport (IIS 6)

Je crois bien que Passport est maintenant obsolète. Je ne m'en suis jamais servi en tout cas.

Digest et Base sont les seuls définis par la RFC 2616 [8], il s'agit de protocoles issus des travaux de l'IETF. Digest n'est proposé que dans un serveur de domaine.

L'authentification intégrée concerne deux modes: Kerberos et NTLM. IIS emploie Kerberos si les conditions minimales suivantes sont réunies:

- IIS 5
- IE 5
- Windows 2000
- Même domaine ou domaine approuvé
- Kerberos est activé!!!

Dans le cas contraire NTLM est utilisé.

Vous trouverez en bibliographie un document intéressant sur les différences entre ces modes [7].

IIS applique les règles suivantes [5]:

- Si l'authentification anonyme est sélectionnée, alors c'est le premier mode qui est proposé quelles que soit les autres sélections
- Si Base est sélectionné ainsi que Digest ou Authentification intégrée. Alors ces derniers sont essayés avant Base
- Si Authentification intégrée est sélectionnée, alors Kerberos est essayé avant NTML

Voyons d'abord comment les choses se passent entre le navigateur et IIS à l'aide de Fiddler.
Pour nos tests nous disposerons d'une simple page avec juste un contrôle LoginName. Configurez le site en authentification Windows, mais sans interdire les accès anonymes.
Bien sûr vous déclarez le site dans un répertoire virtuel pour lancer la page d'accueil depuis votre navigateur favori et non pas Visual Studio ou sinon configurez VS pour utiliser IIS.
Lancez vos pages en utilisant une url avec l'adresse IP plutôt que localhost afin d'éviter des effets de bord.

Les réglages se font depuis IIS. On va sélectionner un par un les différents modes et examiner se qui se passe.

Authentification anonyme

Une seule session interceptée. La réponse est un code 200 qui signifie que tout va bien.

Dans ce mode le navigateur client n'intervient pas. IIS propose à Windows les informations d'authentification (credentials) pour IUSR_MACHINE stockées dans sa métabase à l'aide d'une des méthodes de logon des API Windows.

Le point important est que le client ne fournit aucune vérification d'identité, IIS se charge de tout.

LoginName est vide puisqu'il n'y a pas d'authentification.

Attention:
Pour les tests suivants, n'oubliez pas de désélectionner l'authentification!

Authentification Base

Vous lirez ici [8] ce que signifient Domaine par défaut (realm) et Domaine (domain). Les valeurs par défaut nous suffirons.

Côté Fiddler on trouve deux sessions cette fois.

La première correspond à la requête GET d'origine pour réclamer notre page.
Le serveur répond avec un code 401, code qui nous est moins familier. La section 10 de la RFC 2616 détaille l'ensemble des codes possibles. Le 4 signifie que quelque chose se passe mal (souvenez vous du 404). IIS définit des sous code [5] qui ne s'affichent que dans les logs afin de préciser le problème. Par exemple 401 propose 7 sous-code de 401.1 à 401.7. Fiddler fournit l'information sous forme d'un message.

Dans notre cas ce code est retourné lorsque la requête n'est pas autorisée parce qu'une authentification est réclamée.

L'entête de la réponse laisse voir un nouvel élément:

WWW-Authenticate: Basic realm="XXXXX"

Cet entête indique au navigateur qu'il doit réussir un chalenge: une authentification Base.

IE affiche alors une popup d'authentification. Lorsque l'on clique sur OK la requête est représentée au navigateur, mais cette fois avec une réponse au chalenge:

Authorization: Basic XXXXXXXX

Le XXXXX désigne le logon et le mot de passe en encodage Base64, donc en clair ou à peu près.
Cet entête va suivre vos requêtes tant que vous resterez authentifié.

La réponse du serveur est une requête avec un code 200 indiquant que tout va bien ainsi que la page réclamée visible dans l'onglet TextView.

Le LoginName affiche le logon fournit dans la popup.

Profitez-en pour aller voir à quoi ressemble TextView lorsque la réponse est 401. Vous reconnaissez la page standard affichée par IIS lorsque l'authentification échoue. Cette page est finalement affichée au bout de 3 échecs.

Authentification Windows

Le début commence comme tout à l'heure avec une requête GET et une première réponse 401.
L'entête est très différent:

WWW-Authenticate: Negociate
WWW-Authenticate: NTLM

Cette fois IIS propose deux chalenges: Kerberos (Negociate) et NTML.

Comme tout à l'heure, le navigateur affiche la popup d'authentification et envoie la réponse au chalenge:

Authorization: Negociate XXXXXXXXXXXXXXX

La réponse de IIS est à nouveau un 401.
Le navigateur réitère alors la requête et cette fois elle est acceptée (code 200). Je ne connais pas la raison de ce double envoi de 401, mais j'imagine qu'il est lié à la façon dont fonctionne Kerberos[9]. Ce protocole authentifie en effet aussi bien le client que le serveur. Pour être honnête, on sort là franchement de mon domaine de compétence.

Par curiosité, faites le même test, mais en remplaçant l'adresse IP par localhost. Cette fois aucune popup d'authentification ne s'affiche. Mais sommes nous authentifiés?

Oui, heureusement. Fiddler laisse apparaître exactement les mêmes sessions que tout à l'heure. Mais les choses se sont faites dans les coulisses.
C'est le comportement par défaut d'IE. Mais ce comportement peut se désactiver dans les options de sécurité.
Notez que par défaut Firefox ne réalise pas d'authentification automatique, mais cette fois encore, on peut l'activer.

Que conclure de tout cela?

Le point important est le pilotage des modes d'authentification à l'aide du code 401.
Comment exploiter cette idée pour implémenter une option "Se connecter avec un autre utilisateur" dans un site ASP?

Avant de proposer la méthode du précédent article, j'ai justement essayé de faire un 401 de la façon suivante:

protected void Button1_Click(object sender, EventArgs e)
{
    this.Response.StatusCode = 401;
    this.Response.Redirect("login.aspx");
}

La page de connexion devant faire une redirection vers la page d'accueil.

Si vous essayez ce code vous accèderez bien à la page d'accueil, mais sans la popup d'authentification.

Un examen de la situation avec Fiddler montre que le protocole d'authentification Windows s'établi, mais hélas il s'agit de l'authentification automatique de IE. Ce n'est pas ce que je voulais.

C'est en essayant de comprendre comment contourner ce mécanisme que j'ai fini par mettre au point la méthode précédente qui du coup ne fait appel à aucun 401, en tout cas pas depuis mon propre code.

Alors figurez-vous que Nicolas Frelat a trouvé une solution. Le truc consiste à insister un peu et envoyer 2 fois le code 401.

Vous faites dans un premier temps une redirection vers la page Login.aspx. Et vous complétez son gestionnaire d'événement Load par le code suivant que j'ai légèrement simplifié:

private const string NegoFlag = "Login.Nego";

protected void Page_Load(object sender, EventArgs e)
{
    if ((this.Request.Headers["Authorization"] == null))
    {
        // pas d'entête d'authentification
        // c'est donc la première fois que l'on arrive 
        // sur cette page

        // on fait le ménage par précaution
        this.Session.Remove(NegoFlag);

        // premier envoi
        this.Response.StatusCode = 401;
    }
    else
    {
        // si l'on arrive ici
        // alors la négotiation Kerberos ou NTLM a commencé

        if (this.Session[NegoFlag] == null)
        {
            // premier passage

            this.Session[NegoFlag] = true; // marquage
            // deuxième envoi, la popup s'ouvre
            this.Response.StatusCode = 401;
        }
        else
        {
            // deuxième passage

            // ménage pour réamorcer le mécanisme 
            // pour une prochaine fois
            this.Session.Remove(NegoFlag);
            // redirection vers la page d'accueil
            this.Response.Redirect("default.aspx"); 
        }
    }
}

Ajoutons avant les appels à Response des this.Response.AppendHeader afin de mieux tracer ce qui se passe et observons avec Fiddler.

Les deux premières sessions sont les sessions observées lors de mon premier essai: IE s'authentifie automatiquement suite au premier envoi du 401.

La troisième session correspond au deuxième envoi de 401. Le sous code 401 passe de Access denied à Unauthorized.

La popup d'authentification Windows s'ouvre alors et le tour est joué. La suite est identique à ce que nous avons vu: envoie de deux 401. J'ignore par contre pourquoi dans ce cas on doit les faire à la main.

Même si je ne comprends pas certains détails de cette méthode, elle me semble plus fiable que la précédente et bien plus simple à mettre en œuvre.

Bibliographie

[1] La page d'accueil de Fiddler :
http://www.fiddlertool.com/fiddler/version.asp

[2] Si vous ne parvenez pas à faire fonctionner Fiddler avec IE 7:
http://www.techheadbrothers.com/astuces.aspx?id=313beaf2-b7b2-4002-b871-ab8889747773

[3] RFC 2616: définition de http 1.1
http://www.w3.org/Protocols/rfc2616/rfc2616.html

[4] Tutoriel Fiddler:
http://www.developer.com/lang/jscript/article.php/3631066

[5] II6 sous Windows Server 2003
Microsoft Press, ISBN: 2 10 0072013

[6] Sur les codes 401.1 et 401.2
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8feeaa51-c634-4de3-bfdc-e922d195a45e.mspx?mfr=true

[7] Les modes d'authentification sous IIS. Document de synthèse en français sur les avantages/inconvénients de chaque mode:
http://msdn.microsoft.com/library/fre/default.asp?url=/library/FRE/vsent7/html/vxconIISAuthentication.asp

[8] Description des protocoles Basic et Digest. Utile aussi si vous souhaitez comprendre les entêtes http qui apparaissent lors d'une négociation d'authentification car le principe est le même pour les autres modes.
http://www.ietf.org/rfc/rfc2617.txt

[9] Fiche Wikkipedia de Kerberos:
http://fr.wikipedia.org/wiki/Kerberos

Mon blog va se mettre au vert pendant quelques semaines ...

J'espère vous retrouver en pleine forme début septembre !

Pascal

Voici le premier de la saga écrit en écoutant un CD de Maria Callas, donc en bonne compagnie.

Le scénario:

Une application Web utilise l'authentification intégrée Windows. Vous souhaitez ajouter un lien "Se reconnecter avec un autre compte".
L'idée est d'afficher la fenêtre popup bien connue et de se reconnecter avec un autre compte Windows.
On dispose de cette fonctionnalité par exemple dans SharePoint.

Je présenterai dans quelques temps une solution faisant intervenir une fenêtre d'authentification ASP. Le problème est que pour ne pas envoyer le mot de passe en clair il faut aussi installer SSL, alors on va faire autrement en demandant à IE d'afficher la popup d'authentification.

J'ai passé des heures sur Internet à chercher une solution et n'ai rien trouvé. Alors après moultes essais, j'ai fini par en inventer une que nous allons regarder ensemble.

Tout assemblage (et AppDomain) .NET se voit attribuer un jeu de permissions qui est fonction des preuves qu'il peut fournir. Celles-ci sont fournies par l'hôte de l'application et sa localisation, c'est la responsabilité du chargeur de code de déterminer et valider ces preuves.
Il en existe 8 dans .NET 2.0, encore que l'on puisse en théorie créer des preuves personnalisées, mais elles sont ignorées par défaut.

Les applications Web sont plus spécialement concernées par Zone en général. Zone se réfère aux zones de sécurité d'Internet Explorer, les 6 valeurs possibles sont:

1. MyComputer
2. Intranet
3. Trusted
4. Internet
5. Untrusted
6. NoZone

C'est la valeur qu'IE affiche en bas à droite du navigateur.

Retenons juste que MyComputer est attribué aux fichiers locaux et Internet ou Intranet sont attribués en analysant l'url du code de base.

Lorsqu'un site Web demande une authentification Windows il y a deux cas de figures:

1. La zone est Intranet, alors par défaut IE obtient directement les informations d'authentification (credentials) de Windows
2. La zone est Internet, alors la popup d'authentification est présentée

La solution à laquelle j'ai pensé est donc de faire croire à IE que le site est soudainement dans la zone Internet.

Le petit tableau de correspondance suivant devrait nous aider à voir comment faire:

Code de base	Zone
C:\toto.exe	MyComputer
http://123.456.789.159/localstart.asp	Internet
www.microsoft.com</td>	Internet
http://www.microsoft.com	Internet
http://www.fourthcoffee.com/process/grind.htm	Internet
http://localhost/localstart.asp	Intranet
http://localhost:8080/localstart.aspx	Intranet
http://monServeur/localstart.asp	Intranet
\\serveur\Sharename\fichier.ext	Intranet

Il n'est pas évident qu'un site Web soit toujours associé à un nom dns, par contre il aura toujours une adresse IP.

Maintenant que les pièces du puzzle sont là, voyons comment les mettre en œuvre.

Commencez par construire une page d'accueil Default.aspx:

<body>
    <form id="form1" runat="server">
    <div>
      <asp:HyperLink ID="HyperLink1" runat="server">
        Se reconnecter avec un autre compte
    </asp:HyperLink><br />
      <br />
      <asp:LoginName ID="LoginName1" runat="server" />
    </div>
    </form>
</body>

Le composant LoginName affiche le compte sous lequel vous êtes authentifié.

Ajoutez dans la propriété NavigateToUrl l'url de votre site en utilisant l'adresse IP de votre serveur. Par exemple:

http://192.168.1.3/MonSite/Default.aspx

Il ne reste plus qu'à lancer:

• Cliquez sur le lien, la popup s'ouvre.
• Saisissez le login avec le nom de domaine si vous êtes dans un domaine ou le nom du serveur autrement, le mot de passe puis cliquez sur OK.

Notre page d'accueil se réaffiche, LoginName enregistre le fait que l'on a changé d'identité.

Peut être n'avez vous pas envi de placer une adresse IP dans un fichier de configuration. Le bout de code suivant va obtenir cette information pour vous.

String HostName = Dns.GetHostName();

// Obtient la liste des adresses IP
// Note: GetHostByName est dépréciée sous .NET 2.0
IPHostEntry Entry = Dns.GetHostEntry(HostName);
IPAddress[] addr = Entry.AddressList;

foreach (IPAddress adresse in addr)
{
    if (adresse.AddressFamily.ToString() == "InterNetwork")
    {
        return adresse.ToString();
    }
}

Vista active par défaut Ipv6 qui prend toujours le pas sur Ipv4. Je ne sais donc pas ce que donne ce code dans cet environnement et d'une façon générale le truc proposé. Mais au besoin la bibliographie fournit une solution adaptée à cet environnement.

Voyons maintenant les pannes prévisibles auxquelles on peut s'attendre.

D'abord la solution ne fonctionne (évidemment) que si IIS est installé et votre site déclaré dans IIS. Avec IIS 5 un simple partage Web devrait suffire.

Vous devez activer l'authentification Windows côté site:

élt;authentication mode="Windows"/>

Vous devez aussi désactiver l'authentification anonyme dans IIS et ne garder que l'authentification Windows intégrée ceci accélèrera légèrement l'accès à la page pour des raisons que nous verrons dans un des prochains trucs.

Pour plus de sécurité j'ajoute toujours dans mon fichier de configuration:

<authorization>
<deny users="?"/>
</authorization>

Ainsi si par accident l'accès anonyme est réactivé dans IIS alors vous disposez d'une sécurité car ils seront refusés par le site (ne riez pas, ça m'est arrivé!).
Si vous êtes vraiment parano, vous pouvez aussi désactiver le compte IUSR_<Machine>. Mais attention aux effets secondaires…

Il y a un autre problème potentiel.

Rien n'empêche un utilisateur de placer le site avec l'url en adresse IP dans la zone Intranet ou la zone de confiance (Trusted). Dans ce cas la solution ne fonctionne évidemment plus.
On ne peut pas y faire grand-chose si ce n'est limiter les risques. Par exemple avec une redirection de façon à ne jamais voir l'url avec l'adresse IP:

Response.Redirect(@"http://localhost/MonSite/Default.aspx");

Que conclure?

Je tiens à être clair: cette solution marche chez moi, mais je suis incapable de dire s'il s'agit d'un hack ou bien d'un honnête code. J'ignore absolument si elle fonctionne en toutes circonstances. Donc testez bien si vous l'utilisez et de préférence dans l'environnement du client.

Voilà, j'espère que ceci vous aidera et j'attends avec impatience des commentaires pour améliorer cette solution ou en marquer les limites.
En particulier j'ai pour l'instant vainement essayé de me servir de fichier de stratégie de sécurité (policy file) pour essayer de faire croire qu'un sous répertoire du site se trouve dans la zone Internet. Je pensais ainsi déclencher notre popup par une simple redirection. Quelqu'un a-t-il des informations?

Pour finir

J'encourage les parisiens à se rendre à la galerie Frédéric Got [3] pour voir une exposition sur les œuvres de Steve Mc Curry [2]. Il s'agit d'un photographe dont si vous ignorez peut être le nom, vous connaissez au moins une de ses œuvres: la photo de la jeune fille afghane au regard vert terriblement perçant prise en 1984 a fait le tour du monde. Elle est maintenant recherchée par la CIA vous vous doutez pourquoi…

Bibliographie

[1] Article sur l'obtention d'adresse IPV4 dans un environnement où IPV6 est activé:
http://aspnet.4guysfromrolla.com/articles/071807-1.aspx

[2] Site de Steve Mc Curry:
http://www.stevemccurry.com/main.php

[3] Le site de la galerie Frédéric Got:
http://www.artchic.com/