[Soluc] Problemas para ingresar en 3w versión 2.9.1 - Usuario o clave incorrecto

SIU-Guaraní SIU-Guaraní 2 - Técnicos
1

Buenas Tardes:

En ambiente de desarrollo estábamos probando la versión 2.9.0, después de algunos ajustes la teníamos funcionando. Luego comenzamos a probar la 2.9.1, para lo cual volvimos a convertir la BD desde 2.7 (que es la versión que tenemos en producción) a 2.9.1 para tener datos más actualizados.

Actualmente está todo funcionando, excepto que no podemos ingresar al 3w. Ya corrí el migrar_claves y me dió OK, revisé los logs de apache y PHP (está habilitado el log de errores) y no encuentro nada, adjunto el log de la aplicación.

Con un usuario de prueba hago que me envíe el mail para cambiar la clave, cambio, se registra la misma en aca_usuarios_ag, pero cuando intento entrar con la nueva clave, me vuelve a decir usuario o clave incorrecta. Por las dudas les comento que el test_conexion se realiza con éxito.

Otra cosa para revisar?

Saludos!

Ezequiel Molina
Fac. de Cs. Agrarias - UNJu

log.txt (9.79 KB)

2

Hola Ezequiel, según el log la falla de autenticación se da por clave inválida. Si migraste claves y además recuperaste contraseña no debería haber inconvenientes.
Tienen la extensión php_mcrypt instalada?
Sino te diría que insertes mas klog en la función ‘ejecutar_login’ del archivo src/siu/modelo/autenticacion/fuente_usuarios_guarani.php, para ver los valores de los parámetros y ver de detectar dónde está fallando.

¿Esto sucede con todos los usuarios?

3

Juliana:

Probé con tres usuarios y siempre el mismo problema. Tengo instalado mcrypt. Te comento que cuando estuvimos tratando de pasar la versión 2.7 a Linux tuvimos un problema con el mcrypt que nunca lo solucionamos ya que después nos pusimos a probar la 2.9.0 y funcionaba bien. El warning de apache decía:

mcrypt_encrypt: Key of size 11 is not supported by this algorithm. Only keys of size 16, 24 or 32 supported

Tal vez tendrá algo que ver? Este es ese hilo: [b]http://foro.comunidad.siu.edu.ar/index.php?topic=8919.msg38453[/b]

Otra cosa que tuvimos que tocar fué el encoding ya que nos daba problemas con ciertos acentos y caracteres especiales.

Respecto a lo que me decías de agregar más klogs…como seria eso?

Saludos!

Ezequiel Molina
Fac. de Cs. Agrarias - UNJu

4

Hola Ezequiel!
En la 2.9.0 entonces les funcionaba correctamente el login? Cambiaron algo respecto de ese ambiente? modificaron la version php? Probaron con la misma base que en el ambiente de la 2.9.0 pero convertida a 2.9.1?

Lo de los klog que digo sería agregarlos en la función para comparar que valores tienen las variables, por ejemplo:


	protected function ejecutar_login($id, $clave)
	{
		$enc = new bcrypt(10);
		$parametros = array('id' => $id );
		$datos_clave = catalogo::consultar('persona', 'buscar_clave', $parametros);
                klog2('datos clave', $datos_clave);

		if (empty($datos_clave)) {
			$this->throw_error_guarani(error_guarani_login::id_inexistente);
		}

		$login_ok = ($enc->verify(md5($clave), current($datos_clave)));
                klog2('md5($clave)', md5($clave));
                klog2('current($datos_clave)', current($datos_clave));
                klog2('$enc->verify(md5($clave), current($datos_clave))', $enc->verify(md5($clave), current($datos_clave)));
		if ($login_ok===false) {
			$this->throw_error_guarani(error_guarani_login::clave_invalida);
		}
		return $datos_clave;
	}

Luego en el log de la aplicación podés ver y comparar el valor de las expresiones que están en cada klog2.

Lo que me llama la atención es que en 2.9.0 no tuvieron problemas y en 2.9.1 sí, porque no cambió nada con respecto de la lógica de la operación de acceso. Y por más que usen una base que no se haya corrido el ‘migrar_claves’, al recuperar contraseña, al menos con ese usuario deberían poder ingresar.

Recordás si cambió algo en el ambiente? Sistema operativo, versión php…?

Con respecto al error del mcrypt, acá http://php.net/manual/es/function.mcrypt-encrypt.php dice algo respecto de la versión 5.6.0 de PHP: ‘Tamaños incorrectos en key y iv ya no son admitidos. mcrypt_encrypt() emitirá una advertencia y devolverá FALSE si los datos de entrada son incorrectos. Anteriormente la clave y el IV eran rellenados con bytes ‘\0’ hasta el siguiente tamaño válido.’. Nosotros desarrollamos y testeamos con PHP 5.4.x

5

Juliana:

Encontramos el problema! El error está en la BD, hubo una confusión durante la conversión. De paso les hago la observación porque les va a servir…En los Script de conversión hay las siguientes carpetas:

2070 a 2080
2080 a 2081
2080 a 2090

A simple vista se podría pensar que no hace falta correr los script de la segunda carpeta ya que esos cambios estarían incluídos también en la tercer carpeta verdad? Bueno, eso fué lo que nos pasó, no se corrieron los de la segunda carpeta y uno de esos script convierte el campo contraseña a 255 caracteres, por lo tanto lo que estaba haciendo era truncar las contraseñas en la BD, nunca iba a coincidir!! Quizá se podría poner un control en el “migrar_claves” que controle el largo del campo. Es solo una sugerencia…

Vamos a volver a convertir la BD desde 270 y probamos, los mantengo al tanto.

Gracias por la ayuda!

Ezequiel Molina
Fac. de Cs. Agrarias - UNJu

6

Hola Ezequiel! Sí en su momento salió con ese nombre y quedó mal. Da lugar a confusiones.
Hay que correr una a una para convertir es decir: 2070 a 2080, 2080 a 2081, 2081 a 2090 (que se llama 2080 a 2090)

El tema de las claves está justamente en la versión 2081, y una de las modificaciones consiste en el largo de las claves. Se extiende la longitud de dicho campo.

Disculpas por el inconveniente.
Avisanos si funcionó!

7

Listo Juliana!

Era ese el problema, volvimos a hacer todo el proceso y ahora funciona correctamente. Doy por cerrado este tema pero estoy abriendo otro por un asunto de error en el reporte de regularidades…Nos vemos en el siguiente hilo jaja!

Gracias por la ayuda!

Ezequiel Molina
Fac. de Cs. Agrarias - UNJu