2011-02-14 12 views
6

He encontrado enormes cantidades de información (es decir, this) sobre cómo manejar errores inesperados en ASP.NET, utilizando los métodos Page_Error y Application_Error, así como la directiva customErrors en Web. config.Visualización de errores esperados para usuarios en ASP.NET

Sin embargo, mi pregunta es cuál es la mejor manera de manejar los errores ESPERADOS. Por ejemplo, tengo una página para mostrar un registro. Cada registro tiene una lista específica de usuarios que pueden verlo. Dado que muchos usuarios pueden tener el rol "Ver registros" que no están en dicha lista, tengo que escribir un código en la página para filtrarlos.

protected void Page_Load(object sender, EventArgs e) 
{ 
    var user = Membership.GetUser(); 
    if (!CanUserViewThisRecord(Request["id"], user.Username) 
    { 
     // Display an error to the user that says, 
     // "You are not allowed to view this message", and quit. 
    } 
    else 
    { 
     // Display the page. 
    } 
} 

¿Cuáles son las mejores prácticas para manejar este tipo de error? Puedo pensar en algunas posibilidades:

  1. Redirigir a una página de error.
  2. Ponga una etiqueta en cada página llamada "lblErrorText". Déjelo en blanco a menos que haya un error.
  3. Genere una excepción y deje que el manejo de errores estándar se ocupe de ello.

Esto se siente como una pregunta básica y por eso me disculpo, pero casi todo lo que he encontrado ha sido en referencia a excepciones inesperadas. No es que ninguna de las posibilidades anteriores sea difícil de implementar, pero me gustaría usar un método estándar recomendado si es posible.

NOTA: Gracias a todos por las respuestas. Quiero aclarar que los usuarios NO tendrían la capacidad de hacer clic en los enlaces a los registros que tienen permitido ver. Esta pregunta es más por el interés de estar a la defensiva. Por ejemplo, dado que el ID del registro está en la URL, alguien podría ingresar el ID de un registro prohibido en la barra de direcciones. O el usuario A que está autorizado puede enviar un correo electrónico al usuario B que no lo está. Parece que no estoy usando las palabras "excepción" y "error" de la manera correcta, pero espero que el escenario tenga sentido.

Respuesta

5

Con el interés de fallar con elegancia, me gustaría ir con la opción de mostrar un mensaje en la página.

Aún mejor es la prevención de errores; si sabe de antemano que el usuario no podrá hacer nada en la página, no le proporcione un enlace. En general, los usuarios solo deben ver las cosas que están autorizados a hacer.

+0

El usuario nunca verá un enlace a una página que no puede ver, pero el ID del registro está en la URL. Estoy tratando de evitar un escenario en el que alguien pueda modificar manualmente la URL para contener el ID de un registro que no está permitido. Este es el caso que estoy manejando aquí. Creo que lo que puedo hacer es intentar poner un control de "Texto de error" en la página maestra, así no tengo que modificar cada página para que esto funcione. – Mike

+1

+1 para el comentario de prevención de errores. Un "error esperado" es un poco contradictorio, si se esperaba, ya deberías haber hecho algo al respecto. En mi humilde opinión, el cambio manual de una URL no se espera. Lo trataría como una excepción, manejado de la misma manera que lo haría con un usuario que ingresa una identificación inexistente en la URL. –

0

De sus tres opciones, la tercera sería mi menos favorecida. En realidad, no es una excepción que un usuario intente ver un registro que le dijo que estaba allí. Redirigir a una página de error es más razonable, como lo es la etiqueta de error. Sin embargo, ninguno es especialmente fácil de usar.

No sé cómo está estructurada su interfaz de usuario, pero me parece que no debe permitir que el usuario intente ver un registro si sabe que el usuario no puede verlo. Es decir, si sabe que el usuario no puede ver ese registro, entonces no le dé la oportunidad de hacer clic en él. Nunca llegue al punto en el que tenga que decir: "No puede ver este registro".

Si no puede evitar que el usuario intente ver el registro, creo que un cuadro de mensaje emergente sería preferible a cualquiera de sus dos primeras opciones.

+0

"Excepción" puede no haber sido la mejor opción de palabras. No estoy enlazando páginas prohibidas, pero el usuario aún puede editar la URL para que contenga una ID de registro que no está permitida, o puede enviar un correo electrónico a un destinatario que no está autorizado. – Mike

+0

@Mike: en ese momento, creo que un mensaje de error "403 Prohibido" está en orden. O algo similar. "¡Oye! ¡No puedes hacer eso!" –

1

Como han mencionado otros, preferiría evitar esto antes de que se envíe, ya sea deshabilitando la funcionalidad para estos usuarios o atrapándolo con javascript antes de que se envíe la página.

, necesitará verificar en el servidor que el usuario puede usar un control, y en tales casos la etiqueta sugerida sería preferible como una solución a las otras 3 proporcionadas.

Sin embargo, una solución adicional sería proporcionar un valor oculto a la página que javascript marca dentro de la página, generando una alerta o un diálogo de error más fácil de detectar que una etiqueta que podría perderse y generar confusión a por qué no pasó nada

Editar en función de los comentarios de la persona que formuló la pregunta: si solo se necesita modificar un número en una URL para apuntar a registros que el usuario no tiene autorización, ¿POST quizás sea un método mejor que GET? De esta forma, la forma en que se maneja este error es menos importante, ya que ningún usuario estándar lo encontraría.

0

en mi opinión esta pregunta es más metodología continuación, tecnología ..

creo que es más adecuado para mostrar el mensaje de error cerca del objeto/acción que causa el error.

si lo envía a otra página que perderá es la orientación y no está claro cuál es la causa de este error.

por lo que en mi opinión es más correcto poner el mensaje de error en la misma página. y tal vez darle la oportunidad de corregir ...

Cuestiones relacionadas