¿Debería codificar para proteger su aplicación de los codificadores incorrectos?

Question

No hay duda de que debemos codificar nuestras aplicaciones para protegerse contra usuarios malintencionados, curiosos o descuidados, pero ¿qué pasa con los colegas actuales y futuros?

Por ejemplo, estoy escribiendo una API basada en web que acepta parámetros del usuario. Algunos de estos parámetros pueden correlacionarse con valores en un archivo de configuración. Si el usuario se equivoca con la URL y proporciona un valor no válido para el parámetro, mi aplicación generará un error al intentar leer desde esa sección del archivo de configuración que no existe. Así que, por supuesto, elimino los parámetros antes de intentar leer desde el archivo de configuración.

Ahora, si otro desarrollador trabaja en esta aplicación, añade otro valor válido para este parámetro que pasaría el proceso de depuración, pero no agrega la sección correspondiente al archivo de configuración. Recuerda, solo estoy protegiendo la aplicación de los usuarios malos, no de los codificadores malos. Mi aplicación fallará

Por un lado, sé que todos los cambios deben probarse antes de pasar a producción y algo así sin duda vendrá en una sesión de prueba decente, pero por otro lado, intento construir mis aplicaciones para resistir el fallo lo mejor posible Simplemente no sé si es "correcto" incluir la modificación de mi código por parte de mis colegas en la lista de posibles puntos de falla.

Para este proyecto, opté por no verificar si la sección relevante del archivo de configuración existía. Como desarrollador actual, no permitiría que el usuario especifique un valor de parámetro que causaría un error, por lo que esperaría que un desarrollador futuro no introduzca un comportamiento en un entorno de producción que podría causar un error ... o al menos eliminarlo. caso durante la prueba.

¿Qué opinas?

Lazy ... ¿o filosóficamente suena?

Answer 1

"Simplemente no sé si es" correcto "incluir la modificación de mi código por parte de mis colegas en la lista de posibles puntos de falla".

No es correcto evitar que sus colegas rompan cosas.

No sabe a qué nuevos propósitos se aplicará su software. No sabes cómo se modificará en el futuro.

En su lugar, haga esto.

Escriba simple software correcto, póngalo en producción y deje de preocuparse de que alguien "rompa" algo.

Si su software es en realidad simple, otras personas pueden mantenerlo sin romperlo.

Si lo haces demasiado complejo, (a) lo romperán de todos modos, a pesar de todo lo que haces y (b) te odio por hacerlo complejo.

Por lo tanto, hazlo lo más simple posible para hacer el trabajo.

Answer 2

Creo que es responsabilidad del desarrollador futuro asegurarse de que no introduzca errores o puntos de falla en su código. Cuando finaliza la sesión del proyecto (¿alguna vez ?!), parte del proceso de firma debería ser al menos que el código se haya presentado como libre de errores, ya que esto limitaría la responsabilidad que tiene para problemas futuros.

Si su código se mantiene en un sistema de control de versiones, sería trivial para usted crear una etiqueta que marcaría el punto en el que entregó su código, lo que le permite comparar la base de código actual con su original. surge un error que alguien puede culpar a usted (¡si este es el ángulo desde el que viene!), lo que le permite demostrar que son los cambios que se han realizado en su implementación original los que causaron estos errores . (Suponiendo, por supuesto, que las implementaciones causan un comportamiento inesperado y no corrigen su código "libre de errores" grin).

Un método que he utilizado en el pasado para garantizar la integridad de los datos (y no es infalible), es verificar una entrada en compensaciones específicas para valores específicos, asegurando que la entrada no esté contaminada.

Espero que ayude.

Answer 3

Parece que está tomando medidas razonables para protegerse contra la incompetencia mediante el restregado de la entrada. No creo que sea responsable de protegerse contra el posible uso indebido de su código o de su mala información. Yo iría más allá y diría que mientras tu código documente explícitamente lo que es y lo que no es una entrada aceptable, entonces has hecho suficiente, especialmente si el código adicional de "comprobación de error idiota" está hinchado o (especialmente) más lento .

Un procedimiento que documenta exactamente qué entradas son aceptables es razonable para una API interna. Habiendo dicho eso, a menudo codigo (sobre) a la defensiva, pero eso se debe principalmente al ambiente en el que estoy y mi nivel de confianza en el resto del código.

Answer 4

Ambas maneras están bien, filosóficamente hablando. Haría el juicio en función de la probabilidad que crees que tiene para que esto suceda. Si puede estar casi seguro de que alguien va a romper su código de esa manera, podría ser de buena educación que proporcione un cheque que lo detecte cuando ocurra.

Si no parece particularmente probable, entonces es solo parte de su trabajo asegurarse de que no rompan el código.

En cualquier caso, sus notas técnicas (u otra documentación apropiada) deben indicar claramente que cuando se realiza un cambio, también se requiere el otro cambio.

Answer 5

Utilizaría un comentario en línea para futuros desarrolladores, o para un desarrollador como yo que tiende a olvidar lo que estaba sucediendo en cada parte de la aplicación después de que no he trabajado en ella durante meses.

No te preocupes por la codificación real para frustrar futuros codificadores, eso es imposible. Simplemente agregue toda la información que necesita para apoyar o extender lo que está haciendo dentro del contexto del código fuente.

Esta es la documentación, como mencionó Steve B. Solo me aseguraría de que no sea externo, ya que eso tiende a perderse.

Answer 6

Lazy ... or philosophically sound?

Lazy ... and arrogant. Al codificar de una manera que hace que los errores aparezcan rápidamente, usted protege la aplicación contra sus propios errores tanto como contra los errores de los demás. Todos cometen más errores de lo que creen.

Por supuesto, en lugar de agregar más código para detectar si el archivo de configuración y la verificación de parámetros coinciden, sería mucho mejor si la verificación de parámetros se basara en el archivo de configuración para que solo haya un lugar donde se agreguen nuevos valores y una inconsistencia no es posible.