Arranque, licencia y acceso#

Esta página reúne los problemas que impiden usar Empowerment Center: el servidor que no arranca, la licencia que no vale, las contraseñas de las conexiones que no se pueden leer y los usuarios que no consiguen entrar. Cada uno se explica como síntoma, causa y solución.

Antes de empezar#

Para la mayoría necesitará acceso al servidor (el fichero de entorno y el registro del backend) y, una vez dentro de la aplicación, el privilegio Administración del sistema.

El servidor no arranca#

El backend se para al arrancar y su registro dice por qué. Léalo con:

docker compose -f deploy/compose.yaml logs backend

Síntoma en el registro	Causa	Solución
«Falta la BD propia de ECenter: defina ECENTER_DB_URL, ECENTER_DB_USER, ECENTER_DB_PASSWORD»	Faltan los datos de la base de datos de ECenter. Con `deploy/compose.yaml` basta `ECENTER_DB_PASSWORD`; sin él, hacen falta las tres.	Defínalas en el fichero de entorno.
«Falta la clave de cifrado de secretos (ecenter.secrets.encryption-key / ECENTER_SECRETS_KEY)»	No hay `ECENTER_SECRETS_KEY`.	Póngala. Si es la primera instalación, genérela con `openssl rand -base64 32`. Si ya existía, recupere la misma: con otra, las contraseñas guardadas no se podrán leer (abajo).
«La clave de cifrado de secretos no está en Base64» o «… debe ser de 256 bits (32 bytes en Base64)»	La clave está mal copiada (un espacio, un salto de línea, cortada).	Cópiela entera, sin comillas ni espacios.
«ECenter necesita la extensión pg_trgm y el usuario … no puede crearla en la base de datos …: dele el permiso CREATE sobre ella (GRANT CREATE ON DATABASE … TO …) o cree la extensión antes con un superusuario (CREATE EXTENSION pg_trgm) y vuelva a arrancar»	La BD propia no tiene la extensión `pg_trgm` y su usuario no tiene permiso para crearla.	Dé al usuario el permiso que dice el mensaje, o cree la extensión como superusuario (`CREATE EXTENSION pg_trgm;` en la BD de ECenter).
«ECenter necesita la extensión pg_trgm y este servidor de PostgreSQL no la tiene: instale sus módulos contrib…»	El servidor de PostgreSQL no tiene los módulos `contrib`.	Instálelos (en muchas distribuciones, el paquete `postgresql-contrib`) y vuelva a arrancar.
La migración falla al crear la extensión `postgis`: `permission denied to create extension "postgis"`, o `could not open extension control file` si no está instalada	`postgis` no es de confianza: no la puede crear un usuario que no sea superusuario.	Instale PostGIS en el servidor y cree la extensión como superusuario antes del primer arranque (`CREATE EXTENSION postgis;`). La imagen de `deploy/compose.yaml` ya lo hace.
No conecta con la BD propia (`Connection refused`, `password authentication failed`)	La BD no está en marcha, la dirección es otra o la contraseña no coincide.	Compruebe `docker compose ps` y los datos de `ECENTER_DB_*`. Con `deploy/compose.yaml`, la contraseña de la BD se fija la primera vez que arranca con el volumen vacío: cambiarla después en `.env` no la cambia en la BD.
El contenedor se reinicia con `OutOfMemoryError`	El montón de la JVM es demasiado pequeño para lo que se calcula.	Suba el límite del contenedor (`ECENTER_BACKEND_MEMORY`); la JVM toma el 75 % de él. Sin límite de contenedor, fije `-Xmx` (véase Instalación).
El backend arranca pero el frontal da 502	El backend todavía está aplicando las migraciones (la primera vez, uno o dos minutos) o no está `healthy`.	Espere y mire `docker compose ps`.

Atención

Las migraciones de la BD propia solo van hacia delante. No arranque una versión anterior de ECenter sobre una BD que ya migró una posterior: restaure la copia de antes de actualizar (véase Mantenimiento).

La licencia no vale#

Síntoma. La franja roja de la parte superior dice el problema de la licencia, la API responde 403 LICENSE_INVALID y la consola tiene abierta la alerta Licencia no válida. Los usuarios pueden entrar, pero no hacer nada; quien tiene Administración del sistema va directamente a Administración › Licencia.

Lo que dice	Causa	Solución
«No hay ninguna licencia instalada»	Instalación nueva, o una BD propia nueva.	Envíe a Action Ware el identificador de la instalación que enseña Administración › Licencia (y el registro al arrancar, «Instalación …») e instale la licencia que le devuelvan.
«La licencia ha caducado»	Pasó su último día.	Instale la renovada. La alerta La licencia caduca pronto avisa 30 días antes.
«La licencia es de otra instalación»	La licencia se emitió para otro identificador: por ejemplo, la de pruebas en producción.	Pida una para el identificador de esta instalación.
«La licencia no es válida»	Está mal copiada o la firma una clave que esta versión no reconoce. Una imagen construida sin la clave pública de Action Ware no acepta ninguna.	Vuelva a pegarla entera. Si persiste, compruebe con Action Ware que la imagen lleva su clave pública.

El identificador de la instalación está en la BD propia: una copia restaurada en otro servidor se lleva la licencia, y una BD nueva necesita otra. Sin licencia válida el servidor sigue en marcha, no se lanzan las tareas programadas y las atrasadas se ejecutan una vez al volver la licencia.

Si la licencia limita los usuarios habilitados y se alcanza el máximo, no se pueden habilitar más (la tarjeta Licencia del Resumen dice «Usuarios habilitados: 50 de 50»).

Las contraseñas de las conexiones no se pueden leer#

Síntoma. Tras reinstalar o mover el servidor, las conexiones dicen «La contraseña guardada no se puede descifrar: vuelva a introducirla», la alerta BD de cliente inaccesible da como motivo que la contraseña guardada no se puede descifrar, y los documentos no calculan.

Causa. ECENTER_SECRETS_KEY ha cambiado (o se ha perdido). Con ella se cifran las contraseñas de las conexiones y la clave privada con que ECenter firma sus tokens.

Solución.

Si tiene la clave anterior, vuelva a ponerla y reinicie: todo vuelve a leerse.
Si no la tiene, vuelva a escribir la contraseña de cada conexión en Administración › Conexiones. La clave de la instalación para firmar tokens se sustituye sola; los tokens de incrustación en vuelo (5 minutos como mucho) dejan de valer.

Importante

Guarde ECENTER_SECRETS_KEY aparte, con la misma protección que la copia de la BD propia: una copia sin la clave no descifra las contraseñas, y la clave sin la copia no sirve de nada.

Un usuario no puede entrar#

Síntoma. La pantalla de entrada dice «Usuario o contraseña incorrectos.».

Causa. Puede ser el login, la contraseña, un usuario inhabilitado o bloqueado: la pantalla no lo distingue, para no revelar qué logins existen.

Solución. En Administración › Auditoría, filtre por Categoría › Accesos, Resultado › Fallidas y el login. La entrada Intento fallido dice el motivo real: «Usuario inhabilitado», «Usuario bloqueado», «Contraseña caducada»… Corríjalo en Usuarios y roles (véase Seguridad).

Síntoma. «Demasiados intentos seguidos. Podrá volver a intentarlo en N s.» y el botón desactivado con la cuenta atrás.

Causa. Tras tres intentos fallidos seguidos, el servidor obliga a esperar antes del siguiente, cada vez más (hasta 60 s). Los intentos se olvidan pasada una hora sin fallos.

Solución. Esperar. Si un usuario lo provoca a menudo, restablézcale la contraseña. Los ajustes están en ecenter.security.login-delay.* (free-attempts, initial, max, reset-after).

Síntoma. «No se puede contactar con el servidor. Inténtelo de nuevo en unos minutos.»

Causa. El frontal no llega al backend (502, 503 o 504): está arrancando, parado o el proxy no lo encuentra.

Solución. Mire docker compose ps y el registro del backend.

El inicio de sesión único falla#

Síntoma	Causa	Solución
«El proveedor de identidad le ha reconocido, pero no tiene un usuario habilitado en Empowerment Center. Pida a un administrador que le dé de alta.»	El proveedor identificó a la persona, pero no hay en ECenter un usuario habilitado con el login que da el proveedor (el atributo `login-attribute` del registro).	Dé de alta el usuario con ese login, o corrija su login con Cambiar login…, o enlácelo por SCIM (véase Seguridad). La auditoría lo anota como Intento fallido con «El proveedor de identidad lo identificó, pero no tiene cuenta habilitada en ECenter».
«No se pudo iniciar sesión con el proveedor de identidad. Inténtelo de nuevo.»	Falló el intercambio con el proveedor: la URL de vuelta no coincide, el secreto del cliente ha caducado, el certificado SAML ha cambiado o el proveedor no responde.	Mire el registro del backend a esa hora. Compruebe en el proveedor que la URL de vuelta es `https://<dirección pública>/login/oauth2/code/<id>` (OIDC) o `/login/saml2/sso/<id>` (SAML).
El proveedor dice que la URL de vuelta no es válida y en ella sale `http://` o un puerto interno	El backend no reconstruye bien la dirección pública detrás del proxy.	Compruebe `ECENTER_PUBLIC_URL` y que el backend lee las cabeceras `X-Forwarded-*` del frontal (`SERVER_FORWARD_HEADERS_STRATEGY=framework`, que ya pone `deploy/compose.yaml`). Si hay otro proxy delante del frontal (el que termina TLS), ponga `ECENTER_BEHIND_PROXY=on` en el frontal y haga que ese proxy envíe `X-Forwarded-Proto`, `X-Forwarded-Host` y `X-Forwarded-Port` (la cabecera `Forwarded` no se usa).
Funcionaba y deja de funcionar a la vez para todos	Ha caducado el secreto del cliente en el proveedor o se ha rotado su certificado.	Renueve el secreto o el certificado en la configuración del registro y reinicie.

Si el inicio de sesión único no funciona y necesita entrar, use el primer administrador, que conserva su contraseña (ECENTER_ADMIN_LOGIN).

La sesión caduca#

Síntoma. Un usuario vuelve a la pantalla de entrada sin haber salido.

Causa. Su sesión caducó por inactividad (30 minutos sin uso, ECENTER_SESSION_TIMEOUT) o llegó a su duración máxima (12 horas desde que entró, ECENTER_SESSION_MAX_DURATION), o un administrador la cerró o cambió su usuario.

Solución. Es lo esperado. La auditoría lo dice: Sesión caducada («Su sesión caducó por inactividad» o que se cerró por un cambio en el usuario) o Sesión cerrada por un administrador. Si los plazos no encajan con su organización, cámbielos (véase Configuración). Con el inicio de sesión único, volver a entrar no pide nada.