ctt-gob-es / fire Goto Github PK

Buenos días,

probando el uso del conector de la FNMT, en una instalación de FIRe 2.3, que firma correctamente con el conector local (usando Autofirma), con un usuario válido en el entorno de PRE de CloudID de la FNMT, al intentar firmar un documento, tras seleccionar el certificado del CloudID sale el siguiente error:

Error 201
Error durante la operación de firma del proveedor FNMT-RCM. Pulse el botón Volver para seleccionar otro proveedor.

Si miro en el fichero log veo esto:

SEVERE: Error en la carga de datos: java.lang.IllegalArgumentException: La URL de destino final no puede ser nula
java.lang.IllegalArgumentException: La URL de destino final no puede ser nula
        at es.fnmt.fire.signature.connector.TrustedXRestHelper.createTripleRedirectionUrl(TrustedXRestHelper.java:520)
        at es.fnmt.fire.signature.connector.TrustedXConnector.loadDataToSign(TrustedXConnector.java:173)
        at es.gob.fire.server.services.internal.PreSignService.service(PreSignService.java:362)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:748)

¿A qué URL se refiere el error? Por si interesa, sí tengo desplegado el servicio de gestión de redirecciones (que se indica en el fichero provider_fnmt.properties)

Gracias por la ayuda.

Hola, buenos días

Desde el Principado de Asturias estamos empezando a hacer pruebas con FIRe.

Sio descargamos FIRe desde https://administracionelectronica.gob.es/ctt/fire, vemos que en el Area de Descargas hay varios WAR (https://administracionelectronica.gob.es/ctt/fire/descargas), y por otro lado el código también está en Github (https://github.com/ctt-gob-es/fire).

Los WAR y el código de GitHub ¿es lo mismo? El código de GitHUb ¿es la versión 2.3b?

Para nosotros es más comodo trabajar con GitHub, ya que queremos desplegar la aplicación en servidores JBoss y nos proporciona más libertad.

Un saludo.

Cuando se intenta firmar un PDF firmado con "Firma certificada" de Adobe Acrobat, muestran correctamente el mensaje "SAF_35: El PDF está certificado" indicando que en efecto no se puede firmar ese documento.
Cuando se crea un lote en FIRe con ese mismo documento, muestra la aplicación en pantalla el mensaje "SAF_20: Error en el proceso local del lote de firma".
Para el caso de firma en lote no se devuelve el error y no hay forma de saber que alguno de los documentos tiene una firma certificada.
No dispongo de licencia de Adobe así que no os puedo pasar un ejemplo de PDF ... lo siento :(

Hola,

actualmente el componente distribuido de .Net obtiene su configuración de los valores establecidos en el Registro de Windows.

Quería saber si está pensado actualizar este componente para que también tenga la funcionalidad de obtener sus valores de configuración de un fichero de configuración .config, al igual que se hace, por ejemplo, en el componente distribuido de Java. En el supuesto caso de tener varias aplicaciones cliente de FIRe desplegadas en un mismo servidor, y que cada una de ellas tuviera un almacén PKCS#12/PFX distinto, con la lógica del componente distribuido actual no sería posible configurar para cada aplicación cliente su almacén PKCS#12/PFX, debiendo compartir todas ellas el mismo almacén, lo cual podría ser un problema.

Muchas gracias y saludos.

Hola,

¿hay algún problema en que subáis la versión del framework del cliente .net de la 4 a la 4.5? El motivo es poder usar TLS 1.2 en la comunicación con FIRe.

Un saludo

La gestión actual de conexiones a base de datos presenta varios problemas.

Por un lado, en la versión 2.3 que es la actual estable, el DbManager mantiene una sola conexión a base de datos, pero la lógica de gestionar cuando la conexión es válida en el método getConnection no es "thread safe", y da problemas cuando hay concurrencia. En nuestras pruebas de preproducción generando una simulación con 3 usuarios concurrentes ya se generan varias excepciones de peticiones que no se pueden completar porque la conexión a base de datos es null.

Vemos que en la versión 2.4, todavía en desarrollo, se ha cambiado el DbManager para obtener conexiones nuevas cada vez que se necesitan. Aunque esta aproximación es mejor, implica que cada thread obtiene su conexión, no es una solución muy eficiente. Las conexiones son costosas de crear y ocupan muchos recursos. También en entornos de mucha concurrencia se puede dar el caso, que se deba ajustar el número de threads con que opera el Tomcat al número máximo de conexiones que puede soportar la base de datos.

En estos casos la mejor aproximación es gestionar un pool de conexiones con un DataSource. Todos los servidores de aplicaciones, y también Tomcat tienen los mecanismos para crear un pool de conexiones a base de datos, y asignarle un nombre JNDI. En la configuración del componente fire-signature (config.properties) o del módulo fire-admin-jsp (admin_config.properties), se podrian cambiar las actuales propiedades, bbdd.driver y bbdd.conn, por una sola bbdd.jndi, con el nombre JNDI del datasource creado en el servidor de aplicaciones.

En la configuración del datasource cada instalación podrá configurar, que número máximo de conexiones quiere, cual es el tiempo máximo de espera si no quedan conexiones disponibles, que métodos usas para comprobar que las conexiones son validas antes de retornarlas, descargando toda esa logica del DbManger que se limitaría a retornar una conexión del datasource. También los datasources suelen permitir definir parámetros o comportamientos adicionales que ahora no se permiten. Por ejemplo, sentencias SQL para fijar parámetros de sessión de la base de datos que deban ejecutarse cada vez que se obtiene una nueva conexión.

En su estado actual, el subproyecto "fire-admin-persistence" no compila por no encontrar las clases del paquete "es.gob.fire.persistence.permissions":

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project fire-admin-persistence: Compilation failure: Compilation failure:
[ERROR] C:\Users\tomas.capote\eclipse-workspace\fire\fire-admin-persistence\src\main\java\es\gob\fire\persistence\service\impl\UserService.java:[51,42] error: package es.gob.fire.persistence.permissions does not exist
[ERROR] C:\Users\tomas.capote\eclipse-workspace\fire\fire-admin-persistence\src\main\java\es\gob\fire\persistence\service\impl\UserService.java:[52,42] error: package es.gob.fire.persistence.permissions does not exist

Hola.

En nuestras pruebas estamos recibiendo siempre como nulo el valor de SigningCert en el objeto FireTransactionResult.

Hay algún motivo para ello? Está implementada esa funcionalidad? Depende de como llamamos a la firma o a ""recoverSign"?

Fijar el defaultHostnameVerifier en la classe es.gob.fire.client.HttpsConnection provoca un "leak" de classloader.

Cuando se carga una aplicación WAR que incorpore fire-client-java esta se carga con un classloader específico.
Al ejecutar el HttpsConnection.getConnection las líneas 311-316:

		HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
			@Override
			public boolean verify(final String hostname, final SSLSession session) {
				return true;
			}
		});

esto provoca que la clase anónima, cargada mediante el classloader específico del WAR este referenciada por HttpsURLConnection. Al hacer un undeploy del WAR, esa referencia se mantiene, dado que las clases mantienen una referencia al classloader con que han sido cargados, eso evita que el GC pueda procesar el classloader del WAR.

Por otro lado, tanto esa línea, como la anterior, que ejecuta HttpsURLConnection.setDefaultSSLSocketFactory(this.ctx.getSocketFactory()); no deberian ser necesarias, puesto que tanto el SSLSocketFactory como el HostnameVerifier se registran en la connexión creada en las líneas siguientes,

		((HttpsURLConnection) con).setSSLSocketFactory(this.ctx.getSocketFactory());
		((HttpsURLConnection) con).setHostnameVerifier(new HostnameVerifier() {
			@Override
			public boolean verify(final String hostname, final SSLSession session) {
				return true;
			}
		});

Error al desplegar el componente de administración debido a que el servlet es.gob.fire.server.admin.service.AppService se ha renombrado a es.gob.fire.server.admin.service.NewAppService. Es necesario actualizar el fichero web.xml para que refleje dichos cambios.

Hola,
para el juego de pruebas necesitamos un usuario cuyo estado de certificado sea WEAK_REGISTRY. En el juego de pruebas todos tienen certificado OK.
Podríais por favor incluir un usuario con esas características.
Gracias.
Un saludo,
ftovarg

Hola,

sólo indicar que los certificados proporcionados para el servicio de prueba:
fire/clavefirma-test-services/src/main/resources/testservice/

se encuentran caducados a 4 de Mayo de 2019, por lo que ahora mismo es complicado hacer pruebas con dichos certificados.

Muchas gracias y saludos.

Me acabo de descargar el proyecto y al ejecutar el comando mvn compile para que se descargue las dependencias y compile el código se lanza el siguiente error:

[ERROR] Failed to execute goal on project clavefirma-test-services: Could not resolve dependencies for project es.gob.clavefirma:clavefirma-test-services:war:2.4-SNAPSHOT: Could not find artifact es.gob.afirma:afirma-core:jar:1.7-SNAPSHOT -> [Help 1]

Al parecer la versión 1.7-SNAPSHOT de la biblioteca afirma-core no está disponible en los repositorios de maven, ¿qué repositorio debo configurar para que se descargue esta dependencias, además de otras posibles dependencias que aún no haya detectado que no son accesibles?