Operational Dashboard - Cambios y Soluciones
Esta página cubre los cambios y correcciones proporcionados a Operational Dashboard para la versión de IPF 2025.1.0
Nuevo
Encabezado de Seguridad de Transporte Estricto Enviado Con Cada HTTP Respuesta
-
El encabezado de Seguridad de Transporte Estricto está configurado para aplicarse a todas las solicitudes y todos los subdominios, asegurando que todo el tráfico se sirva de manera segura a través de HTTPS.
-
La directiva de precarga está habilitada, lo que permite que el dominio sea añadido a la lista de precarga HSTS para una mayor seguridad. (Nota: Este atributo no tiene efecto a menos que el dominio sea añadido con éxito a la lista de precarga.)
-
El atributo max-age es configurable a través del
hsts-max-ageconfiguración.-
ipf.business-operations.auth.http.hsts-max-age
-
por favor, consulte Determinar Entidad de Procesamiento para más detalles
-
El hsts-max-age El valor debe ser incrementado
-
Por defecto, max-age está configurado en 300 segundos (5 minutos). El mínimo recomendado es 31536000 segundos (1 año), pero se aconseja aumentar este valor de manera incremental durante la implementación.
-
Un valor predeterminado más bajo proporciona un período de gracia para las pruebas. Una vez que un navegador aplica HSTS para un dominio, recuerda la política hasta que expire el max-age. Aumentar el max-age es sencillo, pero reducirlo puede ser un desafío debido a la aplicación por parte del navegador.
-
La mejor práctica es comenzar con un valor bajo, probar exhaustivamente y aumentar gradualmente hasta un valor seguro a largo plazo. Puede encontrar más información aquí:https://hstspreload.org/
Funcionalidad para cancelar pagos programados a futuro
-
Se ha añadido la funcionalidad para cancelar pagos programados en el futuro a la ODS Pantalla de resumen de pagos. Esto permite a los usuarios cancelar pagos que tienen un estado global en SCHEDULED o categorías PENDIENTES.
-
Para acceder a esta nueva función, usted debe tener el siguiente permiso: ROLE_PAYMENT_CANCEL
-
El botón de reparación solo estará habilitado si el estado global del pago se encuentra en una de las dos categorías mencionadas anteriormente. El botón de reparación no estará habilitado si el estado global del pago se encuentra en cualquier otra categoría o en el Recall y Bulk páginas de resumen.
-
Los cambios en la configuración del estado global y la introducción de categorías se han explicado en la sección Cambiado a continuación.
NOTA: La funcionalidad de cancelación solo se ha añadido en el frontend, es necesario implementar una solución en el backend para que esto funcione, la cual estará disponible en un futuro cercano.
Fecha de caducidad configurable para JSON Token Web y Cookie
-
La duración de cuánto tiempo un JSON El Token web, así como la cookie, es válido desde el momento del inicio de sesión y puede ser configurado a través de
ipf.business-operations.auth.jwt.expiry. -
El usuario puede proporcionar este valor en segundos, minutos, horas y días. El valor de la duración establecida debe estar entre 1 minuto y 7 días. Si este valor está mal configurado, la aplicación no se iniciará.
-
La configuración predeterminada para esta propiedad es de 1 hora.
Algoritmo de Firma Configurable para JSON Token Web
-
El algoritmo de firma puede ser configurado a través de la configuración
ipf.business-operations.auth.jwt.signature-algorithmjunto con las propiedades adicionales requeridas para que el algoritmo elegido funcione correctamente. -
Los algoritmos soportados son HS512 y ES512.
-
ipf.business-operations.auth.jwt.secretdebe ser definido cuando se elija HS512 como algoritmo de firma. -
ipf.business-operations.auth.jwt.path-private-keyyipf.business-operations.auth.jwt.path-public-keydeben ser definidos cuando se elija ES512 como algoritmo de firma.
Protocolo de Permisos Granulares introducido y aprovechado por la GUI HTM Módulo
-
El Protocolo de Permisos Granulares ha sido creado, el cual es utilizado por el HTM puntos finales en el Panel de control.
-
Los permisos basados en roles actuales siguen en uso para los puntos finales de la rest de los módulos de la interfaz gráfica.
-
ipf.authorisation.conftiene que ser anulado con custom grupos, roles y HTM contextos específicos para aprovechar la autorización granular para usuarios seleccionados para el acceso a HTM tareas. -
Configuración predeterminada incluida en
ipf.authorisation.confreutiliza roles heredados, como ROLE_HTM_VIEWER, ROLE_HTM_EXECUTE, etc., con ámbitos de permiso que replican respectivamente el ámbito de autorización tal como se utilizaban en el protocolo basado en roles. -
El nuevo protocolo viene con su propia terminología y para configurar correctamente los ámbitos de autorización para HTM Módulo GUI, se recomienda estudiar la documentación publicada en detalle:Autorización Granular
Cambiado
La autenticación básica ahora está deshabilitada por defecto
-
La autenticación básica no debe ser utilizada en producción y está deshabilitada por defecto. Está destinada únicamente para fines de desarrollo y pruebas. Actívela con:
-
ipf.business-operations.auth.basic-auth.enabled = true
-
Cambios en la Configuración del Estado Global
-
La configuración del estado global ha sido cambiada de un arreglo de cadenas a un arreglo de objetos. Aquí hay un ejemplo de cómo debería verse ahora:
global-statuses = [
{
name: "Pending",
category: "PENDING"
},
{
name: "Accepted",
category: "ACCEPTED"
},
{
name: "Completed",
category: "ACCEPTED"
},
{
name: "Rejected",
category: "REJECTED"
},
{
name: "Manual Action Required",
category: "MANUAL_ACTION_REQUIRED"
},
{
name: "Scheduled",
category: "SCHEDULED"
},
{
name: "Cancelled",
category: "CANCELLED"
}
]
|
Este es un cambio importante. Si usted tiene un custom La configuración del estado global, debe actualizarla para que coincida con el nuevo formato. El valor del nombre debe establecerse como lo que desee que sea el estado global, y este es el valor que aparecerá en la interfaz de usuario. Cada estado debe ser asignado a una de 6 categorías que tenga el significado más cercano al nombre del estado global. Solo hay 6 categorías de estado disponibles, y no debe asignar una categoría que no exista en la siguiente lista: PENDIENTE, ACEPTADO, RECHAZADO, SE_REQUIERE_ACCION_MANUAL, SCHEDULED, CANCELADO. Puede haber más de un estado en cada categoría. Se han introducido categorías porque impulsan ciertas pantallas.behaviours en la interfaz de usuario, por lo tanto, la interfaz de usuario no funcionará como se espera si la categoría se deja nula. |
Eliminación del Servicio de Usuario Activo
-
A raíz de los cambios de PAY-12897 y PAY-12894, se ha eliminado el servicio de usuario activo.
-
Cualquier referencia a este servicio debe ahora referirse a la tienda ngrx en su lugar como la única fuente de verdad, ya que ya no decodificamos el JWT localmente.
Por ejemplo, si usted utilizó el activeUserService para obtener el usuario que ha iniciado sesión:
this.loggedInUser = activeUserService.getActiveUserInfo();
Esto puede ser reemplazado por
this.store.select(selectActiveUser).pipe(
map((username: string) =>
(this.loggedInUser = username)
));
Esto no se recomienda ya que no debemos ser mapping desde el selector
-
Más bien, debemos manejar el loggedInUser de esta manera.
this.loggedInUser$ = this.store.select(selectActiveUser);
Donde loggedInUser$ es ahora un Observable<string | undefined>
-
Típicamente, no debe hacer referencia al usuario conectado fuera de un efecto a menos que sea con fines de visualización.
Custom Traducciones Suministradas En La Publicación
-
Traducciones predeterminadas para el IPF Operational Dashboard se suministran en la construcción.
-
Cada módulo tiene su propio archivo de traducción con alcance, por ejemplo:`i18n/htm/en.json`
-
Además, ahora existe un archivo de traducción global para términos compartidos o reutilizados con frecuencia:`i18n/en.json`
-
En tiempo de ejecución, las traducciones globales se fusionan con las traducciones específicas. Todas las claves del archivo global son accesibles bajo el espacio de nombres específico. Si la misma clave existe tanto en el archivo específico como en el global, la traducción específica tiene prioridad.
-
-
Las traducciones personalizadas pueden ser suministradas en el momento del lanzamiento al agregar un HOCON archivo en la siguiente ubicación:`config/bizops/i18n/{scope}/{lang}.conf`(ej.
config/bizops/i18n/htm/en.conf)-
Este archivo puede incluir todas o solo algunas de las traducciones definidas. No es obligatorio proporcionar ninguna custom traducciones - Si el archivo falta, la aplicación utilizará los valores predeterminados.
-
Para facilitar esta funcionalidad, todas las traducciones deben agruparse en las siguientes categorías:
-
navegación Elemento
-
título
-
encabezado
-
texto
-
columnHeader
-
rowHeader
-
formField
-
tooltip
-
tab
-
botón
-
advertencia
-
error
-
campoDeMetadatos
Además, se deben seguir ciertas mejores prácticas. Por favor, consulte Directrices de Traducción para más detalles.
Cambios en el enrutamiento debido a cambios en las cookies
-
La cookie ahora está httpOnly lo que significa que ya no tenemos acceso a él en el FE
-
Deberá actualizar la configuración de los proveedores para su aplicación a fin de manejar los cambios realizados en el módulo.
Este es un cambio importante se debe proporcionar routerReducer para el módulo de la tienda y también se debe proporcionar StoreRouterConnectingModule.
Por ejemplo, debe cambiarse de esto:
StoreModule.forRoot(
{},
{
runtimeChecks: {
strictStateImmutability: false,
strictActionImmutability: false
}
}),
A esto:
StoreModule.forRoot(
{
router: routerReducer
},
{
runtimeChecks: {
strictStateImmutability: false,
strictActionImmutability: false
}
}),
StoreRouterConnectingModule.forRoot()
También deberá actualizar su enrutamiento para la ruta raíz para que realmente estemos verificando que el usuario esté autenticado y tenga una Entidad de Procesamiento válida.
{
path: 'app',
canActivate: [ProcessingEntityGuard],
component: AppHomeComponent
},