Actualización Be Aware 360 - Release Notes - Abril 2026

Tipo de actualización: Despliegue Programado

Versiones Generadas (Fecha Liberación):

• 1.231_4 (13/04/2026)
• 1.233_1 (17/04/2026)
• 1.233_16 (22/04/2026)

Última Versión Liberada Abril: : 1.233_16

[1.233_1] Se implementó la separación de los permisos de creación de casos y contactos en permisos más granulares, permitiendo un control más fino sobre las acciones disponibles para cada rol.

Se crearon dos nuevos permisos en el módulo de navegación:

Nota: Los nuevos permisos solo tienen efecto si el permiso base casos.crear o contactos.crear está habilitado para el rol. Es decir, si el rol no tiene permiso de creación general, los botones no se mostrarán independientemente del estado del permiso estándar.

Para mayor información sobre Permisos de Roles, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad de seguridad donde el servicio de recuperación de contraseña (/recovery) permitía determinar si un usuario existía en el sistema a través de diferencias en las respuestas de error.

Se realizaron los siguientes ajustes:

1. El servicio ahora retorna siempre la misma respuesta independientemente de si el usuario existe o no, eliminando la posibilidad de enumeración
2. Se eliminó la devolución de información completa del usuario en la respuesta del servicio de recuperación de contraseña

Para mayor información sobre Autogestión de Contraseñas, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad de seguridad donde los endpoints de la API de login exponían mensajes de error detallados que podían revelar información sensible sobre la arquitectura interna del sistema.

Se realizó un mapeo completo de todos los endpoints de la API de login y se ajustó el código para retornar mensajes genéricos que no revelen detalles internos. Adicionalmente, se configuró una página de error personalizada en Apache Tomcat para que las solicitudes HTTP malformadas no expongan trazas de pila (stack traces) ni información del servidor.

Los ajustes aplican a los siguientes endpoints:

1. /auth, /logout, /loginVisualTime, /checkVisualTimeToken
2. /loginByAzure, /parametros, /loginSSO, /recovery
3. /getAuthMenu, /loginES, /loginWithToken, /validateToken
4. /loginTokenExternal, /theme, /parametrosKeycloak
5. /loginByKeycloak, /login_oauth, /ba360

Para mayor información sobre Seguridad, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad de seguridad donde la función de recuperación de contraseña no contaba con protección contra consumo excesivo de recursos, permitiendo potenciales ataques de denegación de servicio.

Se implementó un mecanismo de Rate Limiting dedicado mediante un nuevo filtro que actúa sobre toda la API de login. El mecanismo implementado:

1. Bloquea el acceso tras 5 intentos fallidos consecutivos
2. Desbloquea automáticamente después de 300 segundos (5 minutos)
3. Aplica a todos los paths de la API de login, incluyendo /recovery

Para mayor información sobre Autogestión de Contraseñas, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad de seguridad donde las URLs de integración con sistemas externos contenían credenciales de usuario codificadas en base64 como parte de la URL. Dado que la codificación en base64 es una transformación reversible, las credenciales podían ser extraídas de forma trivial.

Se rediseñó el mecanismo de autenticación en las URLs de integración con sistemas externos para no exponer credenciales de usuario en la URL, reemplazando el esquema anterior por un mecanismo seguro que no revela información sensible (tokens opacos con encriptación AES-GCM)

Para mayor información sobre integración con sistemas externos, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad crítica de seguridad donde la API utilizada para añadir notas en casos permitía la inyección de código JavaScript malicioso (Cross-site Scripting persistente), posibilitando la captura de tokens de sesión de otros usuarios.

Se implementó la sanitización completa de caracteres especiales de HTML potencialmente maliciosos en las notas de caso

Para mayor información sobre Seguridad, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad de seguridad donde el token de sesión permanecía vigente y utilizable incluso después de que el usuario ejecutaba el cierre de sesión (logout). Esto incrementaba la posibilidad de que un atacante que obtuviera el token pudiera suplantar la identidad del usuario.

Con esta corrección, el token de sesión se invalida correctamente al momento de ejecutar el cierre de sesión, impidiendo su reutilización posterior.

Para mayor información sobre Seguridad, hacer click aquí.

[1.233_16] Se corrigió una vulnerabilidad de seguridad donde el mecanismo de integración con sistemas de telefonía externos utilizaba URLs que contenían credenciales de usuario en texto plano, codificadas únicamente en base64. La contraseña real del usuario (no un token derivado) era parte de la URL, lo que permitía su extracción trivial.

Se rediseñó el mecanismo de integración para reemplazar la exposición de credenciales por un esquema de autenticación seguro que no incluye información sensible en las URLs (tokens opacos con encriptación AES-GCM).

Para mayor información sobre integración con sistemas externos, hacer click aquí.

[1.233_16] Se corrigieron dos casos de exposición de información sensible:

1. API deprecada v10 activa: El endpoint /ba360/apir/v10/usuario/get (versión deprecada que no fue dada de baja) devolvía hashes de contraseña (MD5) de los usuarios del sistema, accesible para cualquier usuario autenticado independientemente de su rol.
2. API key de terceros expuesta: El endpoint /ba360/apir/v11/sistemasexternos/get devolvía URLs completas de integraciones externas incluyendo API keys de terceros embebidas como parámetros.

Con esta corrección, se realizaron los siguientes ajustes:

1. Se dieron de baja los endpoints bajo la versión deprecada v10 de la API
2. Se protegieron las API keys de terceros para que no sean visibles desde el cliente

Para mayor información sobre Seguridad, hacer click aquí.

[1.233_1] Se corrigió una vulnerabilidad de seguridad identificada durante pruebas de penetración donde los endpoints de la API de login exponían mensajes de error detallados que podían revelar información sensible sobre la arquitectura interna del sistema.

Se realizó un mapeo completo de todos los endpoints de la API de login:

1. /auth, /logout, /loginVisualTime, /checkVisualTimeToken
2. /loginByAzure, /parametros, /loginSSO, /recovery
3. /getAuthMenu, /loginES, /loginWithToken, /validateToken
4. /loginTokenExternal, /theme, /parametrosKeycloak
5. /loginByKeycloak, /login_oauth, /ba360

Se identificó que el endpoint /auth/keycloak (función loginByKeycloak) devolvía mensajes de error directos en la respuesta. Se ajustó el código para retornar mensajes genéricos que no revelen detalles internos. Adicionalmente, se revisó la configuración de Tomcat para no mostrar páginas de error con información del servidor.

Para mayor información sobre Seguridad, hacer click aquí.

[1.233_1] Se corrigió una vulnerabilidad de seguridad identificada durante pruebas de penetración donde la función de recuperación de contraseña no contaba con protección contra consumo excesivo de recursos, permitiendo potenciales ataques de denegación de servicio.

Se implementó un mecanismo de Rate Limiting dedicado mediante un nuevo filtro RateLimitFilter.java, extrayendo la lógica existente de la clase LoginAPI a un filtro independiente registrado en web.xml. De esta forma, el filtro actúa exclusivamente sobre toda la API de login y no solo sobre el servicio /auth.

El mecanismo implementado:

1. Bloquea el acceso tras 5 intentos fallidos consecutivos
2. Desbloquea automáticamente después de 300 segundos (5 minutos)
3. Aplica a todos los paths de la API de login, incluyendo /recovery

Para mayor información sobre Autogestión de Contraseñas, hacer click aquí.

[1.233_1] Se corrigió una vulnerabilidad de seguridad identificada durante pruebas de penetración donde el servicio de recuperación de contraseña (/recovery) permitía determinar si un usuario existía en el sistema a través de diferencias en las respuestas de error.

Se realizaron los siguientes ajustes en el código de LoginAPI:

1. El servicio ahora retorna siempre la misma respuesta independientemente de si el usuario existe o no, eliminando la posibilidad de enumeración
2. Se eliminó la devolución de información completa del usuario en la respuesta del servicio de recuperación de contraseña

Para mayor información sobre Autogestión de Contraseñas, hacer click aquí.

[1.233_1] Se corrigió un defecto en el módulo de Lista de Chequeo donde, al crear o editar una lista de chequeo de tipo Caso, el selector de workflow (proceso) permitía seleccionar procesos inactivos. Solo debería permitir la selección de procesos activos.

Para mayor información sobre Listas de Chequeo, hacer click aquí.

[1.233_16] Se corrigió un defecto que provocaba la visualización de una pantalla de error genérico “Error Internal Server” durante la operación en la consola de Be Aware 360. Con esta corrección, el sistema gestiona adecuadamente las solicitudes que anteriormente generaban este error, garantizando la continuidad de la operación del usuario.

Para obtener más información sobre información técnica de Be Aware 360, haga clic aquí.

[1.233_16] Se corrigió un defecto en el cual no se cargaban correctamente los correos electrónicos del contacto ni las casillas de verificación en la pestaña Notas dentro del detalle de un caso. Con esta corrección, al acceder a la pestaña Notas, el sistema recupera y muestra correctamente los correos asociados al contacto y las casillas de selección correspondientes.

Para obtener más información sobre gestión de casos, haga clic aquí.

[1.233_1] Se corrigió un defecto en el módulo de Lista de Chequeo donde, al crear o editar una lista de chequeo de tipo Caso, el selector de workflow (proceso) permitía seleccionar procesos inactivos. Solo debería permitir la selección de procesos activos.

El problema se originaba en dos puntos:

1. Backend: El endpoint GET /v11/checklist/workflow/get retornaba todos los workflows sin aplicar filtro por estado activo, ya que realizaba una consulta sin filtros.
2. Frontend: El componente <el-cascader> no filtraba los procesos inactivos del listado recibido.

Con esta corrección, se ajustó tanto el endpoint del backend para filtrar únicamente workflows activos como el frontend para aplicar un filtro adicional que excluya procesos inactivos del selector.

Para mayor información sobre Listas de Chequeo, hacer click aquí.

[1.233_1] Se corrigió un defecto en la versión 12 del motor de workflow donde las acciones de avance (Next), retroceso (Back) y salto manual entre pasos no registraban correctamente los indicadores de SLO (Service Level Objective). Esto provocaba que los tiempos de permanencia en cada paso no se contabilizaran adecuadamente para el cálculo de cumplimiento de niveles de servicio.

Para mayor información sobre Configuración de SLO, hacer click aquí.

[1.231_4] Se corrigió un defecto en el cual el estado del usuario permanecía como “Disponible” en la base de datos cuando la sesión finalizaba de forma no intencional, ya sea por expiración del token, invalidación de credenciales o finalización forzada de sesión desde el backend.

Anteriormente, el sistema solo actualizaba el estado a “Desconectado” cuando el usuario ejecutaba la acción de cierre de sesión de forma explícita. Esta inconsistencia provocaba que el motor de asignación de casos considerara al usuario como disponible, generando asignaciones incorrectas y discrepancias entre el estado real y el registrado.

Con esta corrección, se implementó un mecanismo de limpieza automática que detecta sesiones finalizadas de forma no explícita y actualiza el estado del usuario a “Desconectado” de manera consistente.

Para mayor información sobre Conceptos hacer clic aquí

[1.231_4] Se corrigió un defecto en el módulo de Casos donde los permisos de Chequeo (Checklist) no tenían efecto funcional. La pestaña de Chequeo se mostraba independientemente de los permisos configurados para el rol del usuario.

Con esta corrección, la visibilidad y las acciones sobre el Chequeo de casos ahora respetan los permisos asignados:

Nota: Para que la pestaña sea visible, el usuario debe poseer al menos el permiso checklist.listar o checklist.ver, y además deben existir tareas asociadas al caso.

Para obtener más información sobre gestión de casos, haga clic aquí.

[1.231_4] Se corrigió un defecto en el cual la parametrización general EDICION_CASO_CERRADO_DATOS_CFS permitía la edición de casos cerrados incluso cuando el usuario no contaba con permisos de modificación en su rol. Esto generaba una sobrescritura indebida de los permisos del rol.

Con esta corrección, se ajustó la lógica de validación para que los permisos del usuario tengan prioridad sobre la parametrización general:

1. Si el usuario no posee permiso de modificar, no puede editar el caso independientemente del valor del parámetro.
2. Si el usuario posee permiso de modificar y el caso está abierto, puede editar normalmente.
3. Si el usuario posee permiso de modificar y el caso está cerrado, la edición depende del valor del parámetro de configuración.

Nota: Este ajuste también aplica al bloqueo de edición de notas en casos cerrados, garantizando consistencia en el comportamiento de permisos.

Para obtener más información sobre gestión de casos, haga clic aquí.

[1.231_4] Se corrigió un defecto en el cual la configuración de permisos por rol y proceso para las Vistas 360 funcionaba correctamente en la consola de Be Aware 360, pero no se respetaba al acceder desde Sistemas Externos.

Con esta corrección, se ajustó la lógica de carga y visualización de las Vistas 360 en Sistemas Externos para que aplique el mismo filtrado que la consola, considerando el rol del usuario autenticado (rol principal y roles asociados) y el proceso (workflow) del caso en curso. De esta manera, las Vistas 360 solo se muestran cuando el usuario posee los permisos correspondientes y el caso pertenece a un proceso habilitado.

Para obtener más información sobre integración con sistemas externos, haga clic aquí.

[1.231_4] Se corrigió un defecto en el cual al adjuntar un archivo marcado como privado a un caso, la nota automática generada por el sistema indicaba incorrectamente que el archivo era público.

El problema se originaba en el backend, donde el código encargado de asignar la privacidad a la nota automática se encontraba comentado y además contenía un error en el nombre de la propiedad utilizada. Con esta corrección, al cargar un archivo privado, la nota asociada se crea correctamente como mensaje privado, y al cargar un archivo público, la nota se crea como mensaje público.

Para obtener más información sobre adjuntar archivos a un caso, haga clic aquí.

[1.231_4] Se corrigió un defecto que impedía la creación de nuevos usuarios en Be Aware 360. Los usuarios reportaban que el proceso de creación no se completaba correctamente, bloqueando la operación de administración de la plataforma.

Para obtener más información sobre gestión de usuarios, haga clic aquí.

[1.231_4] Se realizó una optimización en los tiempos de carga al recargar un caso, especialmente durante la ejecución de scripts HTML. Anteriormente, la recarga del caso tras la ejecución de un script invocaba la recarga de todos los catálogos globales (roles, grupos, acuerdos, prioridades, sistemas externos, archivos custom), lo cual era innecesario ya que estos datos no cambian como resultado de la ejecución de un script.

[1.231_4] Se implementó una validación en el proceso de carga de archivos adjuntos a casos para que, cuando se intente subir un archivo que exceda el límite permitido de 12.5 MB, el sistema retorne un mensaje claro indicando que el archivo no pudo ser adjuntado por superar el tamaño máximo.

Anteriormente, al intentar adjuntar un archivo mayor al límite permitido a través de la API, el sistema retornaba un código HTTP 200 con estado “NO OK” sin proporcionar información sobre la causa del rechazo.

Nota: Para archivos mayores a 200 MB, el servidor puede descartar la solicitud antes de que la validación se ejecute. Se recomienda implementar validación de tamaño en el cliente previo al envío

[1.225_0]

• Componente Icono: se dispone de un catalogo de iconos para utilizar en las pantallas asociados al nuevo componente “Icono” en la sección de predefinidos.
• Paleta de Colores: En el contexto del módulo de proyectos, la configuración del proyecto presenta un apartado de estilos donde por el momento se pueden guardar colores asociados al proyecto, estos colores que se carguen aquí van a aparecer para ser seleccionables en las configuraciones de color de los componentes.

[1.223_0]

• Integración de workflows en el módulo de proyectos
• Backup en el historial de versiones, de hasta tres pantallas, de EB con posibilidad de restaurarlas.
• Se soluciona: Cuando el nombre del script tiene guiones, no funciona la sintaxis que actualiza otro componente al llamarlo en un evento ej: nombre-script(datakey). Recibir siempre en el payload de scripts nombre de pantalla, para hacer diferenciaciones si se reutiliza script
• Se reciben datos de elementos adjuntos en el payload del evento onclick
• Se soluciona la configuración de campo requerido para componente datetime

Para obtener más información sobre Experience Builder, haga clic aquí.