Aujourd'hui, je vous propose un petit tour d'horizon des possibilités offertes par IIS et .net pour personnaliser ses pages d'erreurs.
Première chose à assimiler, il ne faut pas confondre les pages d'erreurs de nos applications .net et les pages d'erreur IIS :
- La première catégorie sert principalement à afficher les erreurs internes à nos applications (exceptions diverses)
- La seconde catégorie contient toutes les erreurs clients et applicatifs IIS qui peuvent être utilisée par des applications autres qu'ASP .net (erreurs 400-500 type : page introuvable, site indisponible, accès refusé …)
La première catégorie d'erreur se gère assez facilement via la section customErros du fichier web.config. Il n'y a pas grand-chose à dire. Vous pouvez gérer les erreurs dans vos applications web, et choisir sur quel client on veut ou non afficher les erreurs en détail. Dans certains cas, vous risquez d'être en grosse galère, car les pages d'erreur IIS peuvent prendre le dessus sur vos pages d'erreurs ASP.net. Un développeur .net doit donc avoir connaissance des possibilités offertes par la personnalisation des pages d'erreur IIS.
La seconde est bien plus intéressante car elle offre des possibilités de personnalisations aux hébergeurs et administrateurs système. Ceci de manière uniforme quelle que soit la technologie utilisée. Certes les pages ainsi personnalisées sont en général statiques (pour éviter de donner trop d'informations aux utilisateurs finaux), mais au moins elles sont chartes aux couleurs de la société.
Pour ceux qui n'auraient jamais fait attention, voici une capture du panneau IIS qui met en avant les deux zones de configurations :
Pour présenter correctement la chose, j'ai choisi d'utiliser le plan suivant :
- Activité les erreurs personnalisées IIS
- Scope de la configuration des pages d'erreurs
- Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs
- Possibilité 2 : Embarquer les pages dans son site
- Possibilité 3 : Hébergement sur un serveur dédié
Ma volonté étant de vulgariser les pages d'erreurs IIS pour les développeurs .net, j'omettrai volontairement un certain nombre de détails. Je n'aborderai donc pas des notions comme :
- Les pages détaillées
- Les redirections/réécritures de pages
- La possibilité absolument diabolique d'empêcher les développeurs de personnaliser les pages d'erreurs (c'est méchant ça !)
Attaquons donc dans le vif !
1. Activité les erreurs personnalisées IIS
En soit, l'activation des pages personnalisées n'a rien de bien compliquer. Sur un poste client, il suffit d'aller dans le panneau de configuration t d'ajouter une fonctionnalité Windows.
Ici sur un Windows 8.1 en français : « Erreurs http »
Sur un serveur, il faut ajouter une fonctionnalité au rôle IIS. Ici sur un Windows 2012 R2 qui a déjà cette fonctionnalité activé : « Erreurs HTTP (Installé) »
Aucun reboot n'est utile.
2. Scope de la configuration des pages d'erreurs
La configuration des pages d'erreurs étant enregistrée dans un fichier *.config section system.webServer (nœud httpErrors). Voici ce à quoi ressemble la configuration par défaut :
Il est possible de la modifier à différents endroits :
- applicationHost.config
- web.config
Bien entendu, machine.config ne fait pas parti des possibilités envisageables. Imaginez une page d'erreur qui change en fonction de la CLR ou de la plateforme ciblée (32 ou 64bits). Ce serait un cauchemar !
En fonction de l'endroit où l'on configure la section system.webServer, il est donc possible de personnaliser les erreurs pour :
- Tous les sites d'un même serveur (applicationHost.config)
- Un site (web.config)
- Une application (web.config)
- Un répertoire virtuel ou non (web.config)
La configuration peut donc être très souple. Via la console IIS, on dispose même d'une interface très pratique. Celle-ci permet de changer une page d'erreur existante et d'ajouter/supprimer des erreurs.
Le formulaire de configuration d'une erreur reste simple, à condition de comprendre les trois possibilités de personnalisation offertes par IIS.
3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs
La première possibilité offerte consiste dans l'usage de pages statiques stockées sur le serveur. Il s'agit de la configuration par défaut de IIS. Les fichiers sont stockés dans le répertoire « %SystemDrive%\inetpub\custerr\ » (donc bien souvent dans C:\ inetpub\custerr\).
Si vous le souhaitez, vous pouvez choisir d'utiliser des pages qui diffèrent en fonction de la langue de l'utilisateur (pages localisées). Pour cela, il suffit de créer un répertoire par langue. Exemple : ici le français (fr-FR)
Lors de la saisie, si la case «Essayer de retourner le fichier d'erreur dans le langage client » est cochée, le bouton définir est disponible. Il permet d'accéder au formulaire suivant :
Dans le cas où cette case n'est pas cochée, vous ne pourrez pas avoir de pages d'erreurs localisées. Il faudra donc donner le lien complet vers la page d'erreur.
Voici par exemple, la configuration obtenue en personnalisant uniquement deux pages (401 localisée et 403 non localisée)
Notes :
- errorMode doit être défini sur Custom pour que votre configuration soit prise en compte
- On peut utiliser un noeaud <clear/> si on veut supprimer les autres pages.
4. Possibilité 2 : Embarquer les pages dans son site
Il s'agit là de l'approche préférée des développeurs. Les pages font partie du site. On peut en profiter pour avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).
5. Possibilité 3 : Hébergement sur un serveur dédié
Cette approche est très pratique dans le cas d'une ferme IIS. Les fichiers n'ont pas besoin d'être répliqués sur l'ensemble des serveurs de la ferme. Cette approche comme la précédente permet d'avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).
Voilà, j'espère que cet article vous donnera envie de considérer cette possibilité de personnalisation de IIS.