last day (14 days later) » 

10:04
0
Q: ¿Cómo utilizar pdo mysql en sistemas de CRM?

LukasMi pequeño sistema codificado funciona perfectamente hasta que muchos usuarios la empezaron a utilizar. Actualmente algunos valores en la base de datos se intercambian con valores de otras personas y no encuentro razones. El problema ocurre así: los usuarios hacen updates, luego después de unas h...

¿Es necesario que uses (:customer_db_id)*1 y cosas similares? ¿Qué significa que "intercambian valores"? Las consultas están bien hechas, ¿es posible que el contenido de esas variables las estés obteniendo de manera errónea? ¿Dónde se mezclan los datos? ¿En qué tabla se introducen o están mal? ¿customer_db_id e user_id son la clave primaria o un índice único de lithuania_customers_2016?
No es necesario hacer (:customer_db_id)*1, lo he hecho para ver si evita el problema y no lo evita ... El contenido de las variables provienen de sesión y el contenido es correcto, he hecho testing del mismo. Se mezclan en la tabla lithuania_customers_2016 donde se hacen los updates. La cosa es que cuando ejecutan en esta página todo está correcto, pero después de unas horas el contenido se intercambia automáticamente en la misma tabla lithuania_customers_2016. customer_db_id es primario user_id es primario en tabla de usuarios y se obtiene de sesión.
@OscarGarcia ¿es posible que el error sea por caché de Chrome o alguna cosa así?
Chrome no puede forzar consultas SQL en una máquina remota, aunque deberías hacer lo necesario para impedir que los usuarios pulsen "volver" en el navegador y/o repetir el envío de un formulario dos veces pulsando "actulizar" (por ponerte ejemplos). ¿Me estás diciendo que los datos se guardan bien pero que luego se intercambian valores? ¿Has probado a hacer el histórico mediante un disparador UPDATE de la primera tabla en vez de hacerlo mediante programación?
@OscarGarcia Si, eso es lo que estoy diciendo: se guardan bien y luego se intercambian. No he impedido a que los usuarios hagan "volver", pero no sé cómo eso podría originar problema que tengo ... No tengo ningún disparador (si te refieres a trigger, no lo tengo, ni crojobs ni nada de eso)... Llevo luchando con ese problema semanas y no encuentro ninguna solución :/
Está claro que si los valores se intercambian debe ser por una de las causas que provocan la actualización: o los datos de sesión se corrompen (se intercambian los archivos de unos usuarios por los de otros, cosa poco probable), o algo accede a la base de datos para modificarlos (cosa que estamos investigando) o bien esas variables de sesión están siendo modificadas en algún lado poniéndole valores que no esperas.
10:04
@OscarGarcia debería cambiar el sistema de login ? Por ahora estoy utilizando uno del año 2012 que he encontrado en github .. El problema es que tengo que recodificar muchas cosas, pero si esto resolvería el problema, me espera un fin de semana de mucho trabajo pero por fin tendría la solución.
Si me dices la URL del proyecto te puedo decir si es seguro o no. De todas formas no deberías guardar información importante o volátil en variables de sesión. Todo debería residir en base de datos o en el formulario de la página.
Hola Oscar, gracias por tus respuestas. Te dejo el link: wesscss.com
Eses es el formulario de entrada, me refiero a la URL de github donde está el sistema que usas, para ver si lo hace bien
10:29
Perdona, no lo encuentro :/// estuve buscando todo este tiempo, quizás lo hayan eliminado..
Bueno, ya te comenté en la pregunta que no es buena práctica almacenar datos variables en las variables de sesión
Ahí sólo deben ir variables que identifiquen la sesión del usuario o datos estáticos que no vayan a ser modificados (permisos o niveles de acceso del usuario) que se vayan a usar con frecuencia y se quiera evitar consultar la base de datos constantemente.
El problema está que si se modifican esas variables de sesión en otra página o formulario, luego también estarán en ese modificadas.
10:51
De acuerdo, muchas gracias. Pero entonces no sé cómo organizar los datos, porque siempre he hecho de esta forma: si el usuario de sesión ID es 21, coger los datos de tabla de registros donde ID de usuario es 21 ... alguna otra forma?
Sí, eso es correcto. El identificador del usuario es algo que no cambiará, puedes guardarlo como variable de sesión. Pero me dijiste que todos los datos del formulario los obtienes de la variable de sesión.
Variable de sesión me refería al ID de usuario que está en la sesión ... Por cierto, he encontrado el github: github.com/Draven714/Tutis-Login
Ahí hay un error de seguridad .. acabo de escribir un comentario en requests ..
11:33
Es posible que el error sea porque todos los usuarios estén en el mismo IP ? no, verdad?
11:50
No, no tiene sentido. ¿De dónde obtienes las variables que usas en la consulta?. Hay que delimitar el origen del problema. Te recomiendo que agregues información de depuración en modo texto para hacerte una idea de lo que está pasando.
Por ejemplo: file_put_contents('log_consultas.txt', var_export([ 'sesion' => $_SESSION, 'server' => $_SERVER], true, FILE_APPEND)
Sin tener acceso al proyecto completo ni cómo obtienes esas variables no puedo determinar qué otros factores podrían entrar en juego en los cambios que se realizan.
Me has dicho que entran desde la misma IP.. ¿comparten navegador?
Es decir, ¿pueden usar ordenadores de un aula de informática en el que la sesión de PHP haya sido previamente iniciada con otro usuario y pueda contener información mezclada de sesiones de usuario? ¿Sueles limpiar la variable de sesión y regenerarla tras el inicio de sesión o sólo creas los índices que necesitas en ella?

last day (14 days later) »