Actualizamos un diaguita que venimos utilizando para las pruebas de integración de la 3.0.1 a la 3.2.0
Luego de actualizar y acomodar todo lo relacionado a la integración, al ingresar con un usuario de nuestro SSO que seria el toba de diaguita, el browser muestra esto:
El usuario no posee permisos para acceder al item solicitado.
Y en el log de diaguita sale:
-o-o-o-o-o-
Fecha: 07-07-2022 13:05:14
Operacion: Autentificaci�n de Usuarios
Usuario: no_autentificado
Version-PHP: 7.3.33-4+0~20220627.98+debian9~1.gbp40b3e4
Servidor: XXXX.unlp.edu.ar
URI: /SIU-Diaguita/diaguita/
Host: XXXXX
==========
[INFO][diaguita] PUNTO MONTAJE: se carg� la clase login/ci_login.php del punto de montaje proyecto. El path del mismo es /var/SIU-Diaguita320/php
[INFO][toba] componente(30000177): No hay se�ales de un servicio anterior, no se atrapan eventos
[INFO][diaguita] PUNTO MONTAJE: se carg� la clase login/ei_form_datos.php del punto de montaje proyecto. El path del mismo es /var/SIU-Diaguita320/php
[INFO][toba] componente(30000177): [ callback ] 'conf__cas' no fue atrapado
-o-o-o-o-o-
Fecha: 07-07-2022 13:05:20
Usuario: toba
Version-PHP: 7.3.33-4+0~20220627.98+debian9~1.gbp40b3e4
Servidor: XXXXX.presi.unlp.edu.ar
URI: /SIU-Diaguita/diaguita/aplicacion.php
Referrer: https://XXXXX.unlp.edu.ar/
Host: XXXXX
==========
[INFO][toba] Se detecto cambio de operaci�n. Se limpia la memoria de la operacion
[INFO][diaguita] PUNTO MONTAJE: se carg� la clase extension_toba/diaguita_pers_sesion.php del punto de montaje personalizacion. El path del mismo es /var/SIU-Diaguita320/personalizacion/php
[INFO][diaguita] PUNTO MONTAJE: se carg� la clase extension_toba/diaguita_pers_usuario.php del punto de montaje personalizacion. El path del mismo es /var/SIU-Diaguita320/personalizacion/php
[INFO][toba] Se detecto cambio de operaci�n. Se limpia la memoria de la operacion
[CRITICAL][toba] toba_error_autorizacion: El usuario no posee permisos para acceder al item solicitado.
[TRAZA]
toba_nucleo->autorizar_acceso_item
Archivo: /var/SIU-Diaguita320/vendor/siu-toba/framework/php/nucleo/toba_nucleo.php, lInea 317
toba_nucleo->cargar_solicitud_web
Archivo: /var/SIU-Diaguita320/vendor/siu-toba/framework/php/nucleo/toba_nucleo.php, lInea 94
toba_nucleo->acceso_web
Archivo: /var/SIU-Diaguita320/www/aplicacion.php, lInea 22
Nosotros usamos nuestro SSO y matcheamos usuario de diaguita por email con el del SSO. Para eso gente del SIU nos paso una personalización de la clase de usuario que se ve en el log.
Con la 3.0.1 venia andando barbaro, ahora pasa esto. No sabemos si es que paso algo con los perfiles/permisos al migrar o que.
El error que mencionas “El usuario no posee permisos para acceder al item solicitado.” hace referencia a que no el perfil funcional del usuario no tiene acceso a esa operación, en principio parecería que no está macheando correctamente el perfil funcional en el proceso del login. Por las dudas desde el toba_editor pudieron verificar si están los perfiles funcionales con los checks de las operaciones correctamente y si está vinculado al usuario con el que se quieren loguear?
Por otro lado, la actualización deberían hacerla pasando por la versión 3.1.0, durante esta versión 3.1.0 probaron si pudieron loguearse correctamente?,
Te cuento que volvimos a hacer la actualización desde la 3.0.1 ( con la base inicial ) pasamos por 3.1.0 y luego a 3.2.0 y nos sigue sucediendo lo mismo. Esto es haciendo pruebas con el usuario toba (que seria el superadmin)
Mismo error nos tira si entramos por [toba_usuarios].
Tb probamos sacando la autenticación por SAML y dejando la propia de diaguita, y tira el mismo error.
Algo de la migración rompe lo permisos o se los saca a los usuarios.
Hola Juan Pablo,
Te consulto esa base inicial pertenece a esa instalación en caso contrario, deben regenerar los metadatos de los perfiles funcionales. Es bastante sencillo en esa instalación 3.0.1 ingresar con un superusuario (toba en su caso), ir a la operación “Administración=> Usuarios=> Perfiles funcionales” ingresar a cualquiera de ellos y guardar cambios y eso te va generar los metadatos compilados de los perfiles funcionales. Luego realizar las actualización siguiendo el orden de 3.1.0 a 3.2.0.
Saludos!!!
Hola Juan Pablo,
Al tener una base de otra instalación suele suceder el error de los metadatos compilados de los perfiles, por eso seguí los pasos del mensaje anterior, en caso de que te siga sucediendo lo continuamos por GDS.
Saludos!!!
Hola buenos dias.
Revisaron en ruta_diguita/vendor/siu-toba/framework/php/nucleo/lib/toba_autenticacion.php que este el artributo ‘mail’ en la linea $atributos_validos_usuarios ?
Hola , la verdad no vimos nada de eso que comentas $atributos_validos_usuarios .
Tenemos otra instalación de prueba con 3.0.1 que la habiamos integrado con nuestro SSO y SUDOCU y andaba a la perfección, así que salvo que haya cambiado esa clase en la 3.1.0 no vendría por ahí el problema de los permisos que nos saltan.
Hola Juan Pablo,
Ya se encuentra la respuesta en el GDS, donde aplicamos los cambios para las condiciones que tenemos en la versión 3.1.0 funciona corectamente, teniendo en cuenta los cambios que hicimos en el instalador.env.
Saludos!!!