Me reporta hoy uno de los programadores nuevos un problema con el sistema anticopia del sistema que hice hace casi ocho meses y que desde hace cinco meses revisa otra unidad.

Cambiaron la pantalla de login interna por una externa con photoshop, pero al accesar al certificado via direccion ip, no entra porque se compró a nombre del dominio.

Todo esto porque a alguien se le ocurrió hacer una redirección de puertos a través de las máquinas virtuales.

Tuve que comentar el código antiinyeccciones que evitaba malos referer, y deje este comentario en el código:
=========
El proceso de bloqueo de inyeccion SQL queda desconfigurado por que se supone, por ser https, que usamos DOMINIO.
Cuando usamos direccion ip, parece que es inyeccion , porque una ip no puede correr bajo https AOA deshabilita el sistema de inyeccion de referers, cambiando la condicion a 1<>1 el 18 abr 2011,
basicamente porque la direccion ip desvirtua la llamada normal de posts, y el referrer solo funcionaba por dominio, no por ip. Hacer una regla que considere tanto ip como dominios (www), seria redundante porque estamos hablando de https. Asi que, la decisión tomada por terceras personas de llamar a direccion ip fija, deja de lado a fuerza la validacion de puerto 443, porque entra por 80. Y si lo están corriendo por direccion fija, desde firefox (linux), solo pueden entrar por excepcion autorizada de
seguridad, asi que, de entrada no se respetan los criterios de seguridad.

A opinion de AOA, este puede ser un punto de inyeccion SQL. Es responsabilidad de otro checarlo.

Solución real: no redirects. La pantalla que pide el login deberia ser parte de este código, no el añadido, que deshabilitó la original ya incluida en este archivo. El problema tiene origen estético, y DESCONOZCO como llaman o entran desde maquinas virtuales. AOA 18 ABR 2011.

Esta semana que pasó fue bastante movida. Por principio de cuentas no solo encontré como transformar cierto contenido de sitios antiguos a un formato mas utilizables, sino que por fin, una dependencia gubernamental me dió acuse de recibo para mover algunas cosas de Lobo gris a Lobonegro, con lo cual puedo desaparecer ese cluster.

Esta semana estaré haciendo varios ajustes, y además hoy por fin me dejaron a cargo del proyecto RVM. Formalmente ya lo estaba, pero no me habían dado la explicación de que querían. En el transcurso de mañana hago las especificaciones funcionales.

La semana pasada me encargaron revisar el problema de un cliente del corporativo con Femsa y con una dependencia gubernamental. Por mi experiencia con esa dependencia en el pasado (en un asunto absolutamente externo y anterior), se que lo normal que se le hagan envios o entregas de un solo producto a la vez.

Sabiendo eso, esperé que me diera unos datos el de ventas:

1 ) cuantos articulos le mandan a la dependencia en un solo documento ?
2 ) pedi las claves del cliente con la dependencia.

Que bueno que por mi experiencia previa no empecé. Resultó que el problema complejo nunca me materializó. Asi que, preparandome para el caso de un solo producto, avisé que iba a revisar el historial del cliente del corporativo en el sistema que yo diseñé y que ahora lleva otra unidad de negocio.

Entre al sistema, y tres errores. Existe un solo documento y no cientos de historial… y al entrar a ese documento tres errores no verificados.

Al comentar aquí me dice esa unidad que no se ha sincronizado la máquina virtual (regresaron al modelo original de negocio que me habían dicho que siempre no, pero complicado con las máquinas virtuales).

Así que como no tengo acceso a la máquina virtual, y no hablo con clientes, o saco un ejemplo de aire, o espero a que me den más información.

Por cierto, de los dos nuevos programadores uno de ellos ha faltado casi cinco dias que yo me dé cuenta desde que entró, y eso que para su experiencia (casi nula) gana mas o menos bien. Mi sueldo es cinco o seis veces mayor al suyo.

Eso les pasa por contratar sin examen, y por dejar de seguir las especificaciones originales.

Por cierto, el cliente era una de las implementaciones estrellas del jefe de esa unidad… y si no sincroniza los datos, ni la pc virtual, no resulta funcional ese «sistema de implementaciones», porque no solo no es tolerante el proceso a fallas, sino que tiene demasiados puntos de falla.

Afortunadamente no tengo que ver con ninguno.

Aunque el proyecto de RVM no se ha empezado, ya les ha provocado quebraderos de cabeza a algunos programadores que no estan habituados a usar XML-RPC.

De momento, ya no me sorprenden pedidos del cliente tipo :

«Me puedes dar la bitácora de las pruebas de la dirección 10.x.x.x por favor ?»

Para cualquiera que conozca internet, es una estupidez pedir ese dato.

Evidentemente tengo mis bitácoras, pero como reviso las cabeceras, no uso los de la Red Local (por el 10.x sabemos que el cliente me pidió datos de SU PROPIA red privada), yo lo que tengo son los datos de su ip pública. Podría guardar los datos de tipo proxy, pero como pueden ser spoofed, solo guardo las cabeceras de la inyección XML-RPC en un campo cabeceras, el contenido en otro cifrado, y por ultimo la dirección ip en un dato de texto llano (al igual que fecha por TIMESTAMP y otros datos obvios , además de los usados por mis controles personales)