Historias de Horror en programación
Con motivo del Jalogüin, les pongo un par de historias de horror, que me tocó vivir en distintos proyectos.
1. El password como llave primaria
En un trabajo hace ya mucho tiempo, me tocó revisar un proyecto que habían realizado otras personas, porque estaban atoradas en una cosa que no les salía. Me hicieron una demo del proyecto (un sitio web ya no recuerdo ni para qué pero era de los típicos que requieren que la gente se registre para entrar y ver o mover cosas). Lo noté algo lento y luego llegamos a la parte problemática y ya me enseñaron el error que salía y todo. Empezamos a ver el código de la página y noté algo raro; la página que fallaba era de las que ya estaban dentro del sitio, no requería autenticación adicional porque el usuario ya se había identificado para entonces y no era algo crucial en cuanto a seguridad se refería; sin embargo, había varias referencias al password del usuario.
Así que empecé a preguntar, y se me fue bajando la presión, como cuando descubres algo horrible, tan horrible que tu cerebro no lo puede procesar, se niega a aceptar esa realidad... el password era la llave primaria de la tabla usuario. Seguramente sus ojos pasaron por esa frase pero su cerebro no la pudo procesar así que ahi va de nuevo: el password era la llave primaria de la tabla usuario.
Bueno, lo primero que me vino a la mente: estaban encriptando el password al menos? si. Pero no le ponían sal, sino que lo encriptaban solito. Cuando encriptas un password normalmente usas un dado adicional, como el nombre del usuario, para que la encripción del mismo password pero con datos adicionales distintos resulte distinta, y de esa manera si Juan y Pedro tienen el mismo password "password", cuando lo encriptas usando como sal "Juan" sale algo muy distinto de encriptarlo usando como sal "Pedro". Pero aquí nada más encriptaban el password solito. De modo que si Juan y Pedro usaban de password "password", el resultado era idéntico en ambos casos.
Entonces, si Juan se registra usando "password", qué pasa cuando Pedro se quiere registrar también usando "password"? Ah pues muy fácil! a Pedro le parece un mensaje de error diciéndole que ese password ya está siendo usado por otro usuario y que por favor escoja uno distinto. Woooooow. Les dejo las implicaciones de esto a su imaginación.
Bueno y después pensé en otra cosa que no sé si es todavía más seria, cuál es la peor de las dos: Si el password es la llave primaria del usuario, entonces cualquier dato relacionado con el usuario debe tener el password, por lo tanto el password seguramente está regado en varias tablas de la base de datos... obviamente, la respuesta era que sí. Vi algunas tablas de la base de datos y muchas tenían un campo "password" que era la llave foránea hacia usuario. Bueno, al menos estaba encriptado... pobremente...
Mi siguiente pregunta: el usuario entonces NO puede cambiar su password, verdad? Pero ellos pensaron que eso era algo importante, el usuario debe de poder cambiar su password, digo, hay que pensar en la seguridad, no? y cómo le hacen, si es la llave primaria? Ah pues muy fácil! Tenían un objeto con un método al que le pasaban el usuario y el nuevo password. De entrada, si el password que querían usar ya estaba en uso por otro usuario, les avisaba y entonces al usuario le salía un mensaje de que no podían cambiar a ese passsword porque estaba en uso por otro usuario (nomás faltaba que les dijera quién!!!). Pero si no estaba en uso por nadie, entonces insertaban un nuevo usuario con un nombre temporal y el nuevo password, y luego iban a hacer updates a todas las tablas que hacian referencia a usuario, poniendoles el nuevo password a los registros que tenian el password anterior, para que apunten al nuevo registro... finalmente, se copiaban ya los datos restantes (como el username, que también tenía una restricción de UNIQUE) al nuevo registro, y se borraba el registro anterior (liberando así ese password viejo para que alguien más lo pudiera usar despues).
Ya nada más pregunté qué hacían cuando había que agregar una nueva tabla al sistema, que hiciera referencia al usuario... fácil! nada más se tienen que acordar de modificar ese procedimiento para que se actualizara también la nueva tabla. Y si quitaban una tabla? lo mismo. Ya en broma les dije que por qué no hacían un stored procedure o algo que revisara todas las tablas de la base de datos y cuando se encontrara una que tuviera una columna "password" la tomara en cuenta para el cambio de password... y les pareció muy buena idea!
Antes de que fueran a implementar ese esperpento de Stored Procedure, me puse a explicarles lo más tranquilamente que pude (que a esas alturas fue a gritos, pero al menos mantuve los insultos a un mínimo), que en todo caso deberían usar el username como llave primaria, no el password... el password debe estar en un solo lugar, no regado por toda la base de datos, aunque esté encriptado. Y el username ya no tienen por qué cambiarlo, así se queda y punto. Y no importa si todos los usuarios deciden usar como password "password"; están en su derecho. Pero si alguien ve la base de datos, todos los passwords deben verse encriptados distinto, aunque sean el mismo.
2. NPE en vez de
Un programador con el que trabajé (brevemente, cabe mencionar) que tenía que hacer un programita para migrar unos datos, tenía que leer algunos registros de una tabla y si existían registros relacionados en otra tabla, actualizar unas cosas, si no existía el registro relacionado, crear otra. Fácil, no? Una llamada a un método para obtener el registro en cuestión, y luego:
cierto?
Pues no... este cuate tuvo la brillante idea de obtener el objeto, y luego poner un try-catch de NullPointerException. En el try ponía todo el código que tenía que ejecutarse si el objeto existía, y en el catch estaba todo el código que se tenía que ejecutar si el objeto no existía. Algo asi:
try { objeto.hazAlgo(); objeto.hazOtraCosa(); /*etc*/ } catch (NullPointerException) { objeto=new Cosa(); /*y luego repetir mucho de lo que venía en el try*/ }
Fue una larga discusión, para convencerlo de que NO era lo mismo, uno por performance, otro porque había tanto código en el try, que bien se podía causar una NPE por otra cosa que no fuera la primera línea dentro del try, y entonces se iba a ejecutar código que no tenía por qué correr... y finalmente por qué carajos alguien va a usar un try-catch en vez de un if? NOOOOOO!!!!!!
Lo peor es que había más de 20 bloques iguales en su código. Y se quejó amargamente de que tendría que cambiarlos todos.
Tiempo después cuando vi Hostel me identifiqué con las víctimas porque recordé el día que vi este diseño de base de datos, y lo del NPE, y me sentí igual. Hubieran podido pasar a un programador o DBA encadenado y luego entra un equipo de programadores maletas a decirle las super ideas que tienen para el sistema usando el password como llave primaria y cómo el try-catch es lo mismo que un if (x == null) {} else {}.
- Inicie sesión o regístrese para enviar comentarios
Jajajaja, que buen
Jajajaja, que buen tema.
Soberbio aquello del password como llave primaria, si es para dar miedo!! xD.
Afortunadamente no he tenido (o no recuerdo, quizá mi mente la bloqueó) una experiencia de ese tipo tan macabro, pero se ve cada cosa... jaja.
--
Javier Benek
Increible lo que puedes
Increible lo que puedes llegar a encontrarte :S
Les dejo un enlace a una anécdota que me pasó cuando iniciaba en este negocio.
---
Aforismos laborales I
---
Saludos a todos!!
"Non nobis domine."
El password como llave
El password como llave primaria, huuum como decía einstein lo más incompresible del mundo es que es comprensible
Una pregunta, NPE significa No PEnd#"%jo ?
JavaRanch big moose saloon member
NPE = NullPointerException
NPE = NullPointerException ;-)
--
Javier Benek
Esa respuesta fué como una
Esa respuesta fué como una sensura con piiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii en televisión ;)
JavaRanch big moose saloon member
NullPointerException
Efectivamente NPE es abreviatura de NullPointerException, comúnmente se abrevia así en foros y documentación informal de reportes de bugs y cosas así. Es lo que este programadorsete estaba usando: accesar un objeto que probablemente no existe, dentro de un try, y en el
Given the choice of dancing pigs and security, users will choose dancing pigs, every single time. - Steve Riley
Creo que nadie entendio....
Creo que nadie entendio.... la pregunta solo era en sentido figurado ;)
JavaRanch big moose saloon member
Bueno pues...
Password como llave primaria jajajajajaja.
Bueno ami me paso algo raro....
de entrada, por cada jsp, generaban un servlet y lo mapeaban como servlet.exe
jajajajaja a verdad y no era un virus, pero cuando ejecute por primera vez el proyecto si me saco un susto(y algo mas) eso no se vale
Javadabadoooo xD
windows...
Programadores de windows seguramente. Piensan que si no le ponian .exe al servlet no se iba a ejecutar, porque pues, a fin de cuentas, es lo mismito que un CGI no? jajajaj.
Given the choice of dancing pigs and security, users will choose dancing pigs, every single time. - Steve Riley
inedito
Vaya que tios, realmente desastroso, uno de mis tios siempre me decia que esta clase de personas existe solo que el problema es dar con ellos
imaginen las relaciones con las demas tablas, en fin que nos sirva de experiencia para los novatos (me incluyo)
Perdon por revivir el post
Bueno algo igual hoirrendo es que vi un sistema que usaba veintitantas bases de datos y pregunte ¿Por que tantas? me imaginaba que fuera un sistema enorme que necesitaba jalar informacion regada por todos lados y de diferentes servidores y cuando veo el porque me dijeron que era porque habia veintitantos usuarios
WTF una base de datos por usuario, woow!!
habia tambien veintitantas paginas de acceso cada usuario con su propiea pagina de acceso) ah y para acabarla de regar veintitantas clases que se conectan a la base de datos... era casi casi como para mejor decirle, oye y si instalas mejor una aplicacion por usuario???
ja, faltaba que dijeran que si... Bueh, cada quien lo suyo, creo que todos tenemos algo chistoso que contar dentro de nuestra experiencia en la chambita
jajajajajajajaja esa de las
jajajajajajajaja
esa de las veintitantas bases de datos estubo buena
acoplandome al tema y
acoplandome al tema y aprovechando para saludarles pues soy relativamente nuevo en la comunidad "aunque les leo desde hace bastante", en mi experiencia nunca me he topado con las aberraciones en el analisis o codigo como mencionaron, pero muy frecuente con
var = var aun asi cuando eclipse te avisa del problema o tambien if(comparacion){}else{el codigo de negacion} "son tan positivos que siempre preguntan por verdadero?" y la vdd me alegran el dia xD
Pseudoprogramadores.com
Ja ja ja estuvo bueno...
Algo parecido me paso a mi
Páginas escolares y encriptaciones...
Eso del password me recordo algo similar que pasa acá en la escuela que es mucho más critico pero que nadie sabe, ni siquiera el wey que programa la web escolar. El caso es que para algunas cosas la página requiere que te "loguies", así que pones un user y un password que te proporcionan cuidadosamente ya que se supone que nadie debe de saber tu contraseña, por el usuario no hay tanto problema. El caso es que al usar un sniffer y escuchar la red nos podemos dar cuenta quién se loguea y con qué password lo hace... Así es señores, la página no usa ningún tipo de encriptación, el programador de la web no ha sabido cómo encriptarla pero bueno ese no es mi trabajo... Lo mío es ver quién se loguea y cuál es su password para hacer desmadres ñ_ñ
.....
Por más que trato, mi cerebro bloquea los recuerdos dolorosos, por defecto.... lo único que recuerdo son, sistemas terminados, nada falla, y todos los usuarios saben lo que hacen.....
Esto les dara muuuchoooo miedo!!
Hablando de DB`s les tengo una historia que vaya que te pega un susto; resulta que curso el 7º semestre de ing en computación y una materia que me inquietaba mucho era bases de datos! cuando comenzo el semestre falte las dos primeras semanas XD y cuando llegue a la escuela oooohhhh mendiga sorpresa que me lleve mi "maestra" de bases de datos es una policia!!! no es por menospreciar ese trabajo pero tener a una maestra de bases de datos que es POLICIA!!!!! caray!! lo que mas miedo me dio fue cuando entre al laboratorio y dijo la maestra: "abran acces!!!" TERRRRRRRROOOOOOOOORRRR!!!! como dice @chochosmx si su cerebro no proceso eso, va de nuevo!
"abran acces!!!"
me quede de a no chingues es broma no??? pero nelson peor que realidad jajaja y aun no termina lo terrorifico!! cuando queria mi maestra crear una nueva base de datos puso lo siguiente: "CREATE DB;" asi!! sin mas ni menos!!! apoco no da miedo tener una mestra asi!! y aun falta pero mejor ahi le paro no se me vayan a infartar!!!
Saludos!
Contraseña en GET
Que les parece
También es de horrror!
Un par de chistes
Estas no son historias de terror, más bien son un par de chistes jaja
Que tal la de mi amigo el Jaciel que algún día después de terminar la carrera hizo una pantalla prototipo de un login parecida a esta:
-----------------------------
Usuario: [ ]
Pasguord:[ ]
[Enviar]
------------------------------
Desde ese día la palabra "pasguord" dejó de ser deprecated y pasó a ser palabra reservada jaja
Otra historia? Va otra
Mi amigo Arturo trabajando en X empresa para IBM
Llega el lider y le pregunta ¿Ya terminaste Arturo? y ese wey bien seguro dice que "sí ya está" (el clásico)
Bueno, mandan a llamar a los usuarios y hacen junta. Cuando empiezan a mostrar lo que hizo ese cuate pues no hacía nada...
Le pregunta de reojo el líder "que onda Arturo" y ese wey dice bueno "ya compila y no tiene errores"
Y que le contesta el lider, osea que ya camina pero todavía no corre? jaja
Mi Historia de Horror en programación
Hace poco tiempo entre a trabajar a una empresa de desarrollo de software, parecía una empresa seria y contaba con excelentes clientes, entregue mi curriculum y en seguida me aceptaron, la primera misión era agregar un módulo a un sistema ya existente, primero que nada mi nuevo y flamante jefe me explicó los requerimientos que debíamos cubrir y en seguida me dijo que toda la interfaz grafica, la lógica del negocio e incluso parte de la base de datos estaba desarrollada "EN ACCESS", me sorprendió mucho porque no era una aplicación sencilla ¡¡incluso era para una cadena de tiendas muy conocida!!!, en fin que era mi primera encomienda en esta empresa y no quise decir que no... en seguida me entregó la aplicación (el sistema completo) para que "me familiarizara con el código y empezara a trabajar": El código no estaba comentado, no contaban con ninguna clase de documentación, el desarrollo no tenía consistencia, parecía código ofuscado (sólo parecía), ERA UN CHILAQUIL!!!!!! Desde luego fue prueba superada, del tiempo que me dieron 80% lo dedique a descifrar y 20% a desarrollar el módulo que me pidieron!!!
RE: Contraseña en GET
Jajaja, antes no se trae la consulta: login?sql="select * from tabla WHERE x = y" (que también lo he visto XD)
Re: Perdon por revivir el post
Jajaja...Antes no tenían veintitantos servers XD
Cambio C por VB
Así es, un Dr. en informática que me da clases de Software Especializado II aka C++ estaba exponiendo un caso para el simple caso de c=a+b; el caso es que en su diapositiva estaba así:
Dim a as integer
Dim b as intenger
Dim c as integer
c = a + b;
Ok, ya ni para que le sigo, estabamos usando DevC++ (No pregunten por qué), simplemente el Dr. dijo que copiaramos el código que tenía que salir una suma y todo bonito. A nadie le salía el código, excepto a su servilleta, todo mejoro cuando dije que el códogio era de VB y no de C++.
Horror!! Un Dr. en informática y no distingue los lenguajes ni en sus propias diapositivas.
Doctores y masters PHP
Es más común de lo que parece. De hecho conozco programadores PHP nivel Master y Senior que ante un simple problemita no son capaces de resolverlo.
En mi servicio social tuve que darles clases de programación a estos "super programadores". El primer ejercicio consistia en realizar la sumatoria del 1 al 10 y ¿qué creen? los señores no pudieron,¿la excusa? "no encontraban la solución en Internet".
PHP
Pointy-Haired Programmer (la versión informática del Pointy-Haired Boss de Dilbert).
Una triste historia...
Programador dejando a su novia
la pesadilla de NPM
el que si me esta sacando canas es el maldito npm de node, tiene muchos cosas que mejorar nada comparado a mvn, esta es la lista de lo que se podria mejorar
1.- en la version pasada lts se tienia un archivo npm-shrinkwrap para evitar que las dependencias cambiaran cuando borrabas el node_module, pues no servia bien
2.- tiene problemas en cambiar el registry publico
3.- cuando uno encuentra alguna dependencia en el registry privado quiere salir a internet a buscala
no recuerdo que esto pasara con java nunca tuve ningun problema con las dependencias
Skuarch, no sé si aplique
Skuarch, no sé si aplique para tu escenario pero, ¿ya checaste WebJars?
->
.
.
yarn
Mis historias
En mi caso.
Formando parte de un grupo de desarrollo con una empresa de cosmeticos, acostumbrabamos programar las liberaciones.
En aquella ocasion, dentro del proceso de facturacion, me tocaba liberar un cambio importante, y otro grupo de trabajo liberaria otro proceso que iba a continuacion del mio. La cosa era que el deadline estaba muy proximo, y justamente le recortaron recursos (programadores) al otro grupo de trabajo, x lo que el lider de proyecto-programador se chuto solito sus ultimos cambios sin descanso.
Llegado el dia de la liberacion, trono lo que tenia que tronar, que fue justamente el proceso inmediato luego del nuestro que tambien habia sido liberado. La cosa es que el otro amigo estaba sin dormir 2 dias y trataba de corregir el problema. Yo entre a echarle la mano pero tambien estaba ya cansado y no le venia pies ni cabeza.
Finalmente incluso llego la Gerente de Sistemas y francamente le dije que yo ya no podia y tiraba la toalla y que el otro compañero tambien estaba muy cansado. Esto seguro no le gusto nada a la Gerente.
Entro otro desarrollador quien empezo a liberar "programitas correctores".. asi se chuto como 3 programitas que iba metiendo luego de cada proceso que veia que los datos iban quedando mal.
Fue una pesadilla.
Al cabo de un tiempo deje de laborar en la empresa. Un amigo me comento que en el cierre de mes que me retire, el proceso volvio a tronar como chinampina justo por otra liberacion del compañero que habia hecho los "programitas correctores", siendo que siempre les enfatize que las pruebas previas eran cruciales antes de liberar y que no deberian escatimar recursos (programadores) en proyectos de impartancia.
------------------------------
En otra ocasion previa, en es misma empresa, revisando un problema con unos numeros que no me salian de mercancias del Almacen de Premios, hice un analisis de producto entregado como premios x la facturacion vs el producto que salia del almacen, encontrando que durante los 2 años pasados habian estado saliendo varios productos de manera duplicada, entre otros: colchones, refrigeradores y lavadoras. Todo debido a un proceso de programacion incorrecto (proceso que yo habia recibido heredado cuando tome las riendas del modulo).
Dicho producto no era entregado a los compradores pero si eran recogidos por "alguien" que habia detectado la duplicidad y no lo reportaba. Cuando reporte eso al gerente del almacen solo me pidio en reunion con el Gerente de Sistemas que no hiciera mas aspavientos y finalmente termino corriendo a personal de confianza que laboraba con el y que seguramente estaba involucrado.
------------------------------
En otra empresa a la que ingrese a dar soporte, vi codigo que no me caia bien a bien lo que hacia.. finalmente rastreando las operaciones en la database halle que simultaneamente se daban accessos de "write" y "delete" por lo que el registro se grababa finalmente miles de veces que luego eran borrados por el mismo programa (concurrencia). Una vez resuelto el problema hable con el programador y le pedi que me diagramara un "if then else", me dijo llanamente que no sabia como hacerlo. De alli estuve un par de horas explicandole los diagramas y le referi a manuales para que se mejorara su codigo.