2009-02-02 6 views
4

Je suis en train de remplacer le gestionnaire d'événements onError d'un formulaire Web pour permettre « Une valeur Request.Form potentiellement dangereuse a été détectée à partir du client » erreurs de type à traiter au sein de la forme plutôt que de mettre fin au niveau du gestionnaire d'erreurs au niveau de l'application.le traitement des demandes de validation « en silence »

J'ai trouvé quelques exemples de code comme ceci:

protected override void OnError(EventArgs e) 
{ 
    // At this point we have information about the error 
    HttpContext ctx = HttpContext.Current; 

    Exception exception = ctx.Server.GetLastError(); 

    string errorInfo = 
     "<br>Offending URL: " + ctx.Request.Url.ToString() + 
     "<br>Source: " + exception.Source + 
     "<br>Message: " + exception.Message + 
     "<br>Stack trace: " + exception.StackTrace; 

    ctx.Response.Write(errorInfo); 

    // -------------------------------------------------- 
    // To let the page finish running we clear the error 
    // -------------------------------------------------- 
    ctx.Server.ClearError(); 

    base.OnError(e); 

} 

qui attrape de façon satisfaisante l'erreur et écrit un message d'erreur sur l'écran, mais ce que je veux vraiment faire est d'être conscient de l'erreur lorsque les feux de Page_Load et ainsi être en mesure d'afficher un message d'erreur «normal» sur le formulaire Web.

Je suis sûr qu'il y a un bon moyen de le faire mais je ne le sais pas! Suggestions ?

(BTW pour diverses raisons, je ne veux pas désactiver le contrôle à la forme ou le niveau application et ni ce que je veux compter Javascript - merci)

Répondre

4

Vous pouvez réellement attraper l'erreur au niveau de la page, mais il va tuer le cycle de vie de la page. Donc, vous devez utiliser un truc pour contourner cela. Exemple:

public override void ProcessRequest(HttpContext context) 
{ 
    try 
    { 
    base.ProcessRequest(context); 
    } 
    catch(HttpRequestValidationException ex) 
    { 
     context.Response.Redirect("HandleValidationError.aspx"); 
    } 
} 

HandleValidationError.aspx peut être quelque chose, y compris une redirection de retour à la même page (peut-être avec un querystring avec des informations sur l'erreur, par exemple "ContactForm.aspx error = non valide + demande?")

0

Je ne pense pas que vous serez capable de gérer l'erreur dans l'événement Page_load. Dans les événements de validation ASP.NET Page Life cycle se produisent après le chargement de la page.

Peut-être que vous pouvez ajouter un div masqué (< asp: Panel Visible = false ...) qui contient votre "message d'erreur normal". si l'événement OnError se déclenche, afficher le message d'erreur div.

jason

1

Je pense que je comprends ce que vous voulez faire, mais je crains qu'il ne serait peut-être impossible. Lorsque votre page ASP.NET effectue une publication, un nouveau thread est créé sur le serveur pour gérer la demande. Avant même que votre cycle de vie de la page ait une chance de commencer, le XSS incriminé est trouvé et une exception est levée. Une fois cette exception levée, vous êtes "expulsé" du cycle de vie de la page ASP.NET et vous ne pouvez pas l'entrer de nouveau. À ce stade, la seule chose que vous pouvez faire du côté client est de sortir l'erreur, ou de rediriger vers une page d'erreur. Ce que vous voulez faire, c'est attraper l'exception, l'écrire quelque part sur la page, et continuer avec le cycle de vie de la page ASP.NET (restaurer l'arborescence de contrôle, restaurer viewstate, appeler des gestionnaires d'événements, etc.). Le problème est qu'une fois qu'une exception non gérée est levée, vous n'avez plus accès au cycle de vie de la page ASP.NET. Dans ce cas particulier, il n'y a nulle part où placer un bloc try/catch car l'exception est générée en interne depuis le cycle de vie ASP.NET avant que votre propre code ne soit appelé.

Je sais que vous avez dit que vous ne voulez pas compter sur Javascript, mais dans ce cas je pense que l'utilisation de Javascript est la seule façon d'obtenir le comportement que vous voulez. Vous pouvez toujours conserver la validation côté serveur, juste au cas où vos utilisateurs désactiveraient Javascript ou entreraient une entrée que votre Javascript ne gère pas.