Comment gérer les fichiers manquants sur MVC

Question

Quelle est votre façon préférée de gérer les appels aux fichiers qui n'existent pas dans votre application MVC?

J'ai quelques applications web fonctionnant avec MVC et ils obtiennent constamment des hits pour les dossiers de fichiers etc. qui n'existent pas dans la structure de l'application.

Apps lancent exception: Le contrôleur pour le chemin n'a pas pu être trouvé ou il ne met pas en œuvre iController

Je suis en train de trouver la meilleure façon de gérer cela.

J'ai 3 routes globales sur mon fichier global.asax (voir ci-dessous) et à ce point je suis heureux avec cette définition simple. Je sais que si j'ai ajouté la définition de route pour tous les contrôleurs, je peux ajouter une définition pour ignorer le reste et gérer ces hits mais s'il sera possible de résoudre ce problème sans cela, je ne veux pas ajouter de définitions d'itinéraire pour chaque contrôleur. croire va inonder les définitions d'itinéraire et aussi ajouter une couche de maintenance que je n'aime pas.

//Aggregates 2nd level 
      routes.MapRoute(
       "AggregateLevel2", 
       "{controller}/{action}/{id}/{childid}/{childidlevel2}", 
       new { controller = "Home", action = "Index", id = "", childid = "", childidlevel2 = "" } 
      ); 

      //Aggregates 1st level 
      routes.MapRoute(
       "AggregateLevel1", 
       "{controller}/{action}/{id}/{childid}", 
       new { controller = "Home", action = "Index", id = "", childid = "" } 
      ); 

      routes.MapRoute(
       "Default", 
       "{controller}/{action}/{id}", 
       new { controller = "Home", action = "Index", id = "" } 
      ); 

Answer 1

En général, il s'agit d'une erreur valide ce que vous voulez vraiment, c'est juste ne pas obtenir un écran de mort jaune.

Les bonnes nouvelles sont, c'est facile. Dans votre fichier web.config, il y a une balise appelée customErrors qui a probablement son mode défini sur remoteOnly (sauf si vous l'avez modifié). Si tel est le cas, le gestionnaire d'erreurs personnalisées ASP.net traitera déjà les demandes ayant échoué comme lorsque la requête ne provient pas de localhost. Si vous voulez voir ce comportement lorsque vous êtes sur votre boîte de dev fonctionnant localement, changer le mode à "On".

Le comportement prêt à l'emploi consiste à gérer l'erreur sur les contrôleurs avec l'attribut HandleError appliqué. Cela fonctionne plutôt bien, et vous pouvez gérer différentes erreurs différemment en passant des argumetns à cet attribut. Normalement, l'attribut affichera simplement les informations d'erreur dans une vue Error.aspx (située par défaut dans votre dossier partagé), qui recrée simplement une déclaration indiquant qu'il y a eu une erreur.

Le comportement que vous recherchez peut vous obliger à changer tout cela, auquel cas vous devez créer votre propre attribut qui hérite de IExceptionFilter et faire ce que vous voulez. De plus, il est toujours possible de surcharger l'OnError de l'application dans global.asax ou dans un module, comme ASP.Net normal.

Answer 2

Cela peut être totalement la mauvaise façon de le faire mais sur mon site privé, j'ai ceci dans le fichier global.asax;

protected void Application_Error(object sender, EventArgs e) 
    { 
     HttpException httpException = Server.GetLastError() as HttpException; 
     RouteData routeData = new RouteData(); 

     routeData.Values.Add("controller", "Error"); 
     routeData.Values.Add("action", "Index"); 
     routeData.Values.Add("statusCode", httpException.GetHttpCode().ToString()); 

     Server.ClearError(); 

     IController errorController = new MyDomain.Controllers.ErrorController(); 

     errorController.Execute(new RequestContext(new HttpContextWrapper(Context), routeData)); 
    } 

Ensuite, j'ai un contrôleur d'erreur;

public class ErrorController : Controller 
{ 
    public ActionResult Index() 
    { 
     //log out the error 
     //string statusCode = RouteData.Values["statusCode"].ToString(); 

     return RedirectToAction("Index", "Home"); 
    } 

} 

Donc, je ramène toujours l'utilisateur à ma page d'index en cas d'erreur. Ceci est seulement un site privé, donc il y a beaucoup de libertés que je peux prendre et mon avis est aussi que moins vous affichez un écran jaune, et moins vous donnez d'informations aux pirates potentiels, mieux c'est.