.gif)
Comment maintenir le bon fonctionnement de mon site et des modules complémentaires avec Internet Explorer 8 ?
Sommaire :
Pour les sites
Chaîne User-Agent et vecteur de version
Accessibilité
Pour les modules complémentaires
Amélioration des contrôles ActiveX
Navigateur faiblement couplé
Protection de la mémoire DEP/NX
Administration des modules complémentaires
Chaîne User-Agent et vecteur de version
Deux éléments risquent d’influer sur la compatibilité des sites, à savoir : la chaîne User-Agent, identité du navigateur transmise aux sites Web via HTTP, et le vecteur de version, mécanisme permettant d’obtenir le numéro de version d’Internet Explorer utilisé dans l’évaluation des commentaires conditionnels. Suivez les pratiques recommandées ci-dessous pour la détection du navigateur afin que votre site continue à fonctionner correctement en cas de consultation par des clients Internet Explorer 8.
Pratiques recommandées pour la chaîne User-Agent :
Si vous souhaitez vérifier que les clients Internet Explorer 8 reçoivent le contenu élaboré et testé pour Internet Explorer 7, utilisez l’opérateur de comparaison supérieur ou égal à (>=) plutôt que égal à (=). Vérifiez également que le mode de rendu du document (excentrique ou strict) est compatible avec Internet Explorer 8.
Exemple
function getInternetExplorerVersion()
// Returns the version of Internet Explorer or a -1
// (indicating the use of another browser)
{
var rv = -1; // Return value assumes failure
if (navigator.appName == 'Microsoft Internet Explorer')
{
var ua = navigator.userAgent;
var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
if (re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
}
return rv;
}
function checkVersion()
{
var msg = "You're not using Internet Explorer.";
var ver = getInternetExplorerVersion();
if ( ver > -1 )
{
if ( ver >= 7,0 )
msg = "You're using Internet Explorer 7 or Internet Explorer 8. I should send a quirks or strict mode document."
else
msg = "You should upgrade your copy of Internet Explorer.";
}
alert( msg );
}Si vous souhaitez destiner le contenu exclusivement à Internet Explorer 8 (envoi, par exemple, d’un document dans le dernier mode de rendu conforme aux directives CSS 2.1), utilisez l’opérateur de comparaison supérieur ou égal à (>=). Mieux vaut éviter de recourir à une correspondance exacte, incapable d’évoluer dans le futur. Autrement dit, en cas de sortie d’Internet Explorer 9, par exemple, vous auriez à mettre une nouvelle fois votre site à jour pour pouvoir détecter cette version.
Exemple
function getInternetExplorerVersion()
// Returns the version of Internet Explorer or a -1
// (indicating the use of another browser)
{
var rv = -1; // Return value assumes failure
if (navigator.appName == 'Microsoft Internet Explorer')
{
var ua = navigator.userAgent;
var re = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
if (re.exec(ua) != null)
rv = parseFloat( RegExp.$1 );
}
return rv;
}
function checkVersion()
{
var msg = "You're not using Internet Explorer.";
var ver = getInternetExplorerVersion();
if ( ver > -1 )
{
if ( ver >= 8,0 )
msg = "You're using Internet Explorer 8 or later. I should send you CSS 2,1 content."
else
msg = "You should upgrade your copy of Internet Explorer.";
}
alert( msg );
}Pratiques recommandées pour le vecteur de version :
Pour vous assurer que les clients Internet Explorer 8 reçoivent bien le contenu créé et testé pour Internet Explorer 7, examinez le contenu existant et vérifiez que le bloc de commentaires donne la valeurtrue pour les clients Internet Explorer 8.
Exemple
<head>
<title>Test Page</title>
<!--[if gte IE 7]>
<link rel="stylesheet" type="text/css" href="stylesheets/ie.css" />
<p>Both Internet Explorer 8 and Internet Explorer 7 will receive this style sheet.</p>
<![endif]-->
</style>
</head>Si vous traitez les clients Internet Explorer 8 et Internet Explorer 7 séparément, vous devez utiliser deux blocs de commentaires conditionnels. Premièrement, utilisez un opérateur de comparaison supérieur ou égal à (>=) pour le bloc de commentaires d’Internet Explorer 8. Remarque : Mieux vaut éviter de recourir à une correspondance exacte, qui serait trop restrictive et donc ne prendrait pas en compte les versions supérieures d’Internet Explorer. Autrement dit, en cas de sortie d’Internet Explorer 9, par exemple, vous auriez à mettre une nouvelle fois votre site à jour pour pouvoir détecter cette version. Deuxièmement, utilisez un opérateur de comparaison égal à (=) pour le bloc de commentaires d’Internet Explorer 7.
Exemple
<head>
<title>Test Page</title>
<meta http-equiv="X-UA-Compatible" content="IE=8" />
<!--[if gte IE 8]>
<link rel="stylesheet" type="text/css" href="stylesheets/standards.css" />
<p>Internet Explorer 8 and greater will receive this style sheet.</p>
<![endif]-->
<!--[if IE 7]>
<link rel="stylesheet" type="text/css" href="stylesheets/ie.css" />
<p>Internet Explorer 7 will receive this style sheet.</p>
<![endif]-->
</style>
</head>Pour plus d’informations, consultez le livre blanc Chaîne User-Agent et vecteur de version.
Haut de page
Accessibilité
Zoom Version 2
La fonction Zoom permet d’agrandir ou de réduire l’affichage d’une page Web pour en faciliter la lecture. Elle s’avère particulièrement utile sur des écrans d’affichage franchement grands ou franchement petits. Vous pouvez alors mettre le contenu à l’échelle tout en conservant la disposition de la page. La deuxième version de la fonction Zoom (la première ayant été fournie dans Internet Explorer 7) vise à améliorer le confort actuel. Elle propose une qualité supérieure et une expérience plus prévisible et permanente. Parmi les principales caractéristiques de cette nouvelle fonction, citons la suppression des barres de défilement horizontales dans les scénarios les plus courants et l’introduction de niveaux persistants de zoom.
Pour plus d’informations, consultez le livre blanc Zoom Version 2.
Haut de page
Prise en charge d’ARIA (Accessible Rich Internet Application) du W3C
Selon le W3C, l’ARIA (Accessible Rich Internet Applications) est une syntaxe qui permet de créer des contenus Web dynamiques et des interfaces utilisateur personnalisées pour les personnes atteintes de handicaps. Internet Explorer 8 utilise les rôles, les états et les propriétés d’ARIA pour communiquer avec les technologies d’aide fonctionnelle. Au lieu de créer des pages Web simplifiées à part pour les personnes présentant un handicap, vous pouvez utiliser des balises ARIA dans vos applications Web enrichies pour y inclure des rôles, des états et des propriétés. Par exemple, pour reprendre le comportement créé par un script, vous pouvez définir un élément DIV comme un bouton, une case à cocher ou un autre rôle ARIA.
Pour mieux comprendre la syntaxe ARIA et apprendre à l’utiliser dans vos contenus Web, consultez les documents de travail suivants que le W3C y a consacré :
Pour plus d’informations, consultez le livre blanc Prise en charge d’ARIA du W3C.
Haut de page
Améliorations des contrôles ActiveX
Contrôles ActiveX des sites
Internet Explorer 8 permet de mieux contrôler l’emplacement et le contexte où peuvent intervenir les contrôles ActiveX. Dans cette version d’Internet Explorer, les contrôles ActiveX intégrés en tant qu’objets Web sont présentés à l’utilisateur sous forme de modules complémentaires. Via la boîte de dialogue Gérer les modules complémentaires, le registre ou le verrouillage de sites ATL, il est possible de restreindre l’utilisation des modules complémentaires sur des sites Web spécifiques.
Lorsque des modules complémentaires sont mis en œuvre sur un site Web, la barre d’informations permet aux utilisateurs d’autoriser l’exécution d’un contrôle ActiveX sur l’ensemble des sites Web ou uniquement sur le site actif. Les utilisateurs peuvent aisément modifier ce comportement dans la boîte de dialogue Gérer les modules complémentaires d’Internet Explorer 8. Tout comme dans Internet Explorer 7, certains contrôles courants (comme Adobe Flash) seront d’emblée autorisés à s’exécuter sur tous les sites Web de façon à optimiser l’expérience de l’utilisateur.
Pour plus d’informations, consultez le livre blanc Contrôles ActiveX des sites.
Haut de page
Contrôles ActiveX sans droit d’administration
Dans Internet Explorer 8, il n’est plus nécessaire de se connecter en tant qu’administrateur pour installer un grand nombre de contrôles ActiveX existants et futurs. Cette mesure permet de résoudre les problèmes soulevés par les clients à l’égard des versions précédentes où l’administration des contrôles laissait à désirer. Dans Windows Vista, les utilisateurs habituels peuvent désormais installer des contrôles ActiveX dans leurs profils utilisateur sans disposer de droit d’administration. Au cas où un utilisateur installerait un contrôle ActiveX malveillant, le système proprement dit ne serait pas affecté. Dans la mesure où l’installation ne concerne que les profils utilisateur, les risques de corruption et les coûts afférents sont considérablement réduits. Cette fonctionnalité s’appuie sur des caractéristiques propres à Windows Vista ; elle n’est donc pas disponible dans Windows XP. L’installation de contrôles ActiveX sans droit d’administration présente les avantages suivants :
- Les contrôles ActiveX existants n’auront généralement pas à être réécrits pour profiter de cette fonctionnalité. Il suffira de les repackager.
- Cette fonctionnalité ne concerne pas le comportement d’installation des anciens contrôles ActiveX.
Pour plus d’informations, consultez le livre blanc Contrôles ActiveX sans droit d’administration.
.gif)
Haut de page
Le concept LCIE
LCIE (Loosely-coupled Internet Explorer) est un concept architectural qui vise à optimiser le navigateur en cloisonnant ses composants et en supprimant leur interdépendance. Plus particulièrement, le cadre et les onglets d’Internet Explorer sont isolés et font l’objet de processus distincts. Dans Internet Explorer 8, ce cloisonnement permettra d’améliorer les performances et la montée en charge, et facilitera la restauration après incident (pannes ou arrêts).
Cette fonctionnalité risque de nuire à la compatibilité des extensions (ActiveX, objets d’assistance du navigateur ou barres d’outils de l’interface utilisateur) qui utilisent certaines techniques de programmation. Les modifications suivantes risquent d’influer sur ces extensions :
- Une nouvelle fenêtre intermédiaire s’insérera entre chaque onglet et le cadre de l’interface utilisateur.
Les extensions qui se fondent sur la hiérarchie des fenêtres pour localiser la fenêtre du cadre et celle des onglets devront tenir compte de cette nouveauté.
- Le processus du cadre d’Internet Explorer s’exécute à un niveau d’intégrité moyen. Les processus des onglets peuvent s’exécuter à des niveaux d’intégrité faible ou moyen, toujours apparentés à ce cadre d’intégrité moyenne.
Les extensions qui sous-classent le cadre à partir d’un processus d’onglet de faible intégrité risquent de ne plus fonctionner correctement.
- Le cadre et les onglets d’Internet Explorer font dorénavant l’objet de processus distincts.
Les extensions utilisant des techniques d’échanges de messages non prises en charge risquent de ne plus fonctionner correctement. Les extensions utilisant des interfaces COM standards ne seront pas affectées.
Pour plus d’informations, consultez le livre blanc Navigateur faiblement couplé.
Haut de page
Protection de la mémoire DEP/NX
Dans Internet Explorer 7 sous Windows Vista, une nouvelle option portant le nom « Activer la protection mémoire pour contribuer à atténuer les attaques en ligne » est apparue dans les Options Internet du Panneau de configuration. Cette option est également connue sous le nom de DEP/NX pour « Data Execution Prevention/No-Execute ». Lorsque cette option est activée, elle travaille de pair avec votre processeur pour contrecarrer les attaques par saturation de mémoire tamponen bloquant l’exécution de code dans la mémoire non exécutable.
Dans Internet Explorer 8 sous Windows Vista SP1 ou ultérieur, nous activerons cette option par défaut.
Certes, la protection DEP/NX n’est pas une panacée contre toutes les vulnérabilités mémoire. Néanmoins, lorsqu’elle est conjuguée à d’autres technologies comme Address Space Layout Randomization (ASLR), elle empêche l’exploitation des vulnérabilités les plus courantes liées à la saturation de mémoire tampon dans Internet Explorer et dans les modules complémentaires que charge le navigateur. Aucune autre intervention de l’utilisateur ne s’avère nécessaire pour assurer cette protection et aucun message n’est communiqué.
Compatibilité DEP/NX
Dans Internet Explorer 7, la protection DEP/NX était désactivée par défaut pour des raisons de compatibilité. Plusieurs modules complémentaires courants n’étaient pas compatibles avec DEP/NX et ne fonctionnaient pas si Internet Explorer les chargeait alors que la protection DEP/NX était activée. Le problème était principalement dû au fait que ces modules complémentaires avaient été créés à l’aide d’une ancienne version de la bibliothèque ATL. Avant la version 7.1 SP1, ATL s’appuyait sur un code généré automatiquement qui n’était pas compatible avec la protection DEP/NX. Bien que les développeurs des modules complémentaires les plus courants aient sorti depuis des mises à jour compatibles avec DEP/NX, d’autres modules complémentaires risquent de ne pas être réactualisés avant le lancement d’Internet Explorer 8.
Heureusement, de nouvelles API DEP/NX ont été ajoutées aux service packs de Windows pour permettre l’activation de la protection tout en conservant la compatibilité avec les anciennes versions d’ATL. Ces nouvelles API permettent à Internet Explorer d’activer la protection DEP/NX sans nuire au bon fonctionnement des modules complémentaires créés avec d’anciennes versions d’ATL.
Dans les rares cas où un module complémentaire ne serait pas compatible avec la protection DEP/NX, pour des raisons indépendantes de l’utilisation d’un code ATL obsolète, une option de stratégie de groupe sera disponible. Une entreprise pourra ainsi désactiver la protection DEP/NX pour Internet Explorer jusqu’au déploiement d’une mise à jour du contrôle défaillant. Les administrateurs locaux peuvent contrôler la protection DEP/NX en exécutant Internet Explorer en tant qu’administrateur et en désactivant l’option Options Internet / Avancé / Activer la protection mémoire pour contribuer à atténuer les attaques en ligne.
Mesures à prendre par les développeurs
Si vous créez des modules complémentaires pour Internet Explorer, vous pouvez faciliter la transition vers Internet Explorer 8 en prenant dès aujourd’hui les mesures qui s’imposent, à savoir :
- Recompilez l’ancien code ATL avec la version ATL 7.1 SP1 (ou ultérieure). La version 8.0 est présente dans Visual Studio 2005.
- Définissez l’option /NXCompat de l’éditeur de liens pour indiquer que l’extension est compatible avec DEP/NX.
- Testez le code en activant la protection DEP/NX dans Internet Explorer 7 sous Windows Vista.
- Intégrez votre code aux autres défenses disponibles comme /GS, /SafeSEH et ASLR.
Haut de page
Administration des modules complémentaires
L’administration des modules complémentaires a été mise à jour dans Internet Explorer 8 pour que les utilisateurs parviennent plus facilement à localiser, à rechercher et à administrer les barres d’outils et les contrôles exécutés à l’intérieur du navigateur. Introduite dans Windows XP Service Pack 2 (SP2), la boîte de dialogue Gérer les modules complémentaires permet aux utilisateurs de visualiser et d’activer ou désactiver les modules actuellement exécutés sur leur ordinateur. Cette boîte de dialogue permet de suivre les modules complémentaires suivants : contrôles ActiveX, objets d’assistance du navigateur, extensions du navigateur, volets d’exploration et barres d’outils. En outre, dans Internet Explorer 8, la liste des modules complémentaires pris en charge par la fonction de gestion s’est enrichie pour inclure les fournisseurs de recherche et les activités dans Internet Explorer 8. Inutile d’apporter de modifications aux contrôles existants ; ils seront toujours administrés dans Internet Explorer 8.
.png)
Pour plus d’informations, consultez le livre blanc Administration des modules complémentaires.
Haut de page