Todas las aplicaciones tienen zonas en las que la probabilidad de que se produzca un error es más alta que en otras partes de del desarrollo. En general son zonas de riesgo los límites de nuestra aplicación. Aquel código que interactúa con el "exterior".
Si analizamos una aplicación de Internet basada en formularios que almacena la información ingresada por los usuarios en una base de datos, entonces, rápidamente identificamos dos zonas de riesgo:
La captura de datos
Recordemos que la información que proviene de los usuarios (esto incluye formularios, querystrings y cookies) no es confiable, puede venir con un formato erróneo o puede no llegar en absoluto. Debemos verificar los datos que recibimos y no confiar en que siempre llegarán correctamente.
Un caso muy común es cuando enviamos, por querystring, el número de página que debemos mostrar. Entonces redirigimos a los usuarios a URLs parecidas a esta:
listado.aspx?pagina=3
Luego en nuestro código escribimos algo así:
int pagina = int.Parse(Request.QueryString["pagina"].ToString());
Los desafío a que busquen páginas de este tipo en Internet y vean lo que sucede si modifican el valor de "pagina" a "abc".
Para que no sucedan estas cosas (las páginas de error no son muy agradables) deberíamos preguntar: "si vino el dato que estoy esperando, y si el dato no es vacío, y si puedo crear un entero, entonces tomar el dato, si no, debo asignar un valor predeterminado". En nuestro ejemplo, ante cualquier problema, pagina valdría "1".
Es cierto que, si por cada dato que queremos obtener debemos escribir tanto código, nuestro programa sería muy extenso, pero también es cierto que, si creamos un objeto que se encargue de obtener estos valores, habremos resuelto el problema para los próximos desarrollos que hagamos.
El almacenamiento de datos
Ya hemos obtenido la información y ahora necesitamos guardarla en una base de datos. Aquí también podemos encontrarnos con errores inesperados ya que existen factores que no podemos controlar. Pueden aparecer errores por clave principal repetida, valores incorrectos, conexiones agotadas, comunicación con la base interrumpida, etc. Otra vez, las páginas de error no son muy amigables. Tenemos que estar preparados y saber que estas cosas, y otras tantas, pueden suceder.
Existen otras zonas de riesgo dependiendo del tipo de aplicación que estemos desarrollando. Debemos identificarlas y tomar los recaudos necesarios para que nuestros desarrollos sean cada vez más robustos.
1 comentario:
La validación del input de usuario es importantísima y más aún cuando se trata de parámetros que vienen por url.
En lenguajes de scripting como ASP es primordial validar primero ya que todo vale, no hay diferencias entre un número y un string, y hace que la página sea vulnerable a SQL Injection si no está preparada de alguna forma.
En lenguajes tipados como los de .NET o Java se puede evitar fácilmente intentando convertir el tipo, si falla se muestra un grosero error pero no rompe nada.
De todos modos coincido con vos en que siempre hay que validar, ya sea por tipo o rangos y en caso de error, mostrar un mensaje más amigable, cambiar el valor a uno por defecto o sino redirigir a la página que le precede a esa.
Publicar un comentario