Comment configurer correctement le fichier web.config d'ASP.NET pour afficher des messages d'erreur spécifiques à l'application, sécurisés et conviviaux pour l'utilisateur dans des cas extrêmes.

Question

Dans notre page web asp.net (.net 4.7.2), nous utilisons une logique de rendu d'exceptions personnalisée qui crée des pages d'erreurs spécifiques pour l'utilisateur dans global.asax.cs via :

Application_Error(object sender, EventArgs e)

Cela fonctionne bien. Cependant, il y a des erreurs asp.net qui n'atteignent jamais l'événement Application_Error.
Pour ces erreurs, nous définissons explicitement une page d'erreur dans le web.config via l'élément customErrors. Cela ressemble à ceci :

Le Problème
Ce qui précède fonctionne bien dans la plupart des cas. Cependant, il y a quelques rares erreurs asp.net qui ne sont pas gérées par l'événement Application_Error et qui font également en sorte que FatalError.aspx lance une exception, même s'il n'y a pas de code asp à l'intérieur. Un bon exemple d'une telle erreur est lorsque vous saisissez l'adresse réservée suivante dans votre navigateur :adresse réservée dans votre navigateur :

https://[votreSiteWeb]/com1

Cela fait en sorte que la page d'erreur par défaut basée sur .aspx affiche le message d'erreur suivant (code d'état Http 500) :

Une exception s'est produite lors du traitement de votre demande. De plus, une autre exception s'est produite lors de l'exécution de la page d'erreur personnalisée pour la première exception. La requête a été interrompue.

Même en définissant un fichier aspx qui ne contient absolument aucun code asp, cela conduit à cette erreur. Il en va de même si l'attribut defaultRedirect est configuré vers une ressource qui n'existe pas ! Cela ne fait aucune différence non plus s'il existe des éléments error définis sous l'élément customErrors, qui définissent la ressource de redirection en fonction d'un code d'état http explicite.

Lorsque le redirectMode de l'élément customErrors est défini sur ResponseRedirect, le gestionnaire d'erreurs par défaut basé sur aspx fonctionne bien. Cependant, ce n'est pas une option, car notre client ne souhaite pas voir de redirection.

En guise de solution de contournement, nous pouvons essayer d'utiliser un fichier html statique. Cependant, dans ce cas, asp.net envoie la réponse sans le bon type de contenu au navigateur et la page HTML est rendue comme du texte.
Il y a beaucoup de publications sur internet qui déclarent que c'est une erreur. Cependant, la solution proposée consiste toujours soit à utiliser un fichier .aspx, soit à utiliser l'événement Application_Error dans global.asax.cs pour définir manuellement le type de contenu dans le code. Cependant, les deux variantes ne sont pas possibles dans cette situation particulière telle que décrite ci-dessus (chaque fichier aspx plante et Application_Error n'est jamais appelé).

Question
Comment pouvons-nous configurer une gestion fiable des erreurs, qui ne montre jamais d'informations d'erreur spécifiques à asp.net mais une spécifique à l'application, même avec des cas particuliers comme décrits dans ce post.
Veuillez noter que la question ne concerne pas comment contourner l'erreur avec les noms de ressources réservées. C'est seulement un exemple et il existe probablement de nombreuses autres circonstances où des erreurs asp.net se produisent, n'atteignent jamais l'événement Application_Error et font planter les fichiers d'erreurs basés sur aspx. L'objectif est vraiment d'avoir un mécanisme pour afficher un message d'erreur de marque d'application au lieu de messages d'erreur asp.net, qui fonctionne de manière totalement fiable.

Aussi en tant qu'observation, nous utilisons également l'élément httpErrors dans la section webServer pour modifier les erreurs qui ne proviennent pas d'asp.net mais de IIS lui-même. Cependant, nous n'avons observé aucune dépendance au problème décrit ci-dessus, donc je ne l'ai pas mentionné dans le texte principal.

Answer 1

Les erreurs ne proviennent pas de Application_Error mais de IIS. Vous pouvez configurer ces erreurs dans web.config dans cette session.

Voici un exemple pour gérer la page non trouvée, ce qui signifie que la plupart des erreurs qui ne passent pas par Application_Error.

L'erreur 403 correspond aux erreurs de refus d'accès.

Comment utiliser Application_Error dans global.asax

void Application_Error(object sender, EventArgs e)
{
    // enregistrer la dernière erreur
    Exception LastOneError = Server.GetLastError();

    string cTheFile = HttpContext.Current.Request.Path;

    if (!cTheFile.EndsWith("PageNotFound.aspx", StringComparison.InvariantCultureIgnoreCase))
    {
        // vérifier pour cela ci-dessus -> fPageNotExist
        // référence: https://stackoverflow.com/a/14032497/159270
        if(fPageNotExist)
            Response.Redirect("~/PageNotFound.aspx");
        else
            Server.Transfer("~/PageNotFound.aspx");
    }
}

et comme vous l'écrivez également utiliser

Les fichiers COM1-9, LPT1-9, AUX, PRT, NUL, CON qui sont des pseudofichiers peuvent être évités en utilisant cette option dans web.config - c'est pour IIS

En activant cette option, vous obtenez de nouveau ces fichiers sous asp.net - mais je ne recommande pas de le faire, car ces requêtes ne proviennent pas de l'utilisation régulière de votre système et peuvent ne pas être bien protégées si vous les mettez sur true.

Formulaires Web et viewStateKey

Pour les formulaires Web, un autre point que je vérifie pour les erreurs est la valeur post de viewStateKey - pour plus de détails, vous pouvez lire cette question/réponse :

CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed