Solucionados bugs #1
Conversation
Si se utilizaba el DnieKeyStore para interactuar con el DNIe, en caso de fallo al introducir mal el pin, había activado un retry automático que fundía todos los intentos. La causa de ello es que DnieKeyStoreImpl pasa un PasswordCallback propio que, al pedirle la contraseña, tan solo devuelve una contraseña que tiene cacheada, en lugar de pedirla al usuario cada vez. Con otros tipos de PasswordCallback implementados en el proyecto sí funcionaba.
…eImpl#engineGetCertificateChain() gastaba dos intentos de pin. Ahora, al primer fallo por pin erróneo, el método lanza una excepción y no continúa.
…ba un valor erroneo El metodo que abre un canal seguro, Dnie#verifyAndLoadCertificates(), hace tres cosas: 1) Abre un canal seguro Cwa14890 2) Verifica que el PIN sea correcto (es ademas el unico metodo que lo hace) 3) Carga los certificados de firma y autenticacion Opino que lo idea seria refactorizar el metodo en tres, pero no me quiero meter en berenjenales ahora... Por otro lado, tenemos el metodo Dnie#isSecurityChannelOpen(), que comprueba solo que se haya realizado la operacion (1) de las anteriores. El problema era que se estaba utilizando Dnie#isSecurityChannelOpen() como precomprobacion para operaciones que requerian que (2) y/o (3) tambien se hubieran producido. Lo he solucionado de manera algo chapucerilla, pero que funciona. Me reitero en que si hubiera recursos y tiempo, lo mejor seria refactorizar ese metodo en dos o tres.
Devolvia una lista con un terminal cuando no habia ninguno conectado.
|
Hola Algonjg, El cambio en Dnie#isSecurityChannelOpen() voy a intentarlo dejar un poco más bonito... |
|
ME alegro de que os pueda servir de algo :) Me suscribo al repo y en cuanto hagáis algun cambio lo re-pulleo. De momento para mis casos de uso voy tirando con mi fork mientras |
|
He subido los cambios vía SVN, con varias salvedades: ¿podrías por favor probar a ver qué tal todo? Quizas tarde unas horas en sincronizar el SVN con el Git. |
|
Gracias! no podré probarlo hasta el fin de semana, pero a priori parece todo correcto. Cerraré el issue cuando lo pruebe si queréis, así no se me pasa :) Edit: @clawgrip Dnie.java sigue teniendo el fallo de AUTO_RETRY en Dnie.java en el ultimo commit que hay aqui en master. ¿Sabes si es pública en algún lado la otra versión que no tiene ese problema? O si no, si hay planes de open sourcearla? Saludos! 👍 |
|
Perdonad, lo voy a tener que dejar para la semana que viene. |
|
Ningún problema. |
|
Buenas tardes, Estoy haciendo mi PFG sobre el DNIe y he encontrado muy interesante el enlace a este github, que entiendo, que es el que implementa el jar ofrecido por la administración para el uso del controlador del dnie en Java. Me preguntaba, si hay un diagrama de clases, de secuencia o cualquier documento de ayuda para entender como funciona el controlador. Mi problema reside es que a la hora de intentar obtener certificados o la firma, pese a que en el manual de usuario se indica que es el propio controlador el que pide el PIN de acceso, a mi no me lo pide incluso si fuerzo a que lo haga por consola (momento en el cual me dice que no hay consola disponible). El código es el siguiente: el error ocurre al intentar obtener el certificado de firma, y esta es la traza: es.gob.jmulticard.card.CryptoCardException: Error en el establecimiento del canal seguro: No se pudo leer certificado de componente: java.io.IOException: Error en la seleccion del certificado de componente de la tarjeta: es.gob.jmulticard.card.iso7816four.FileNotFoundException: Fichero no encontrado: 601F Todo apunta a que hay algún problema con el protocolo cwa14890 a la hora de establecer el canal seguro. No obstante, el almacen lo carga bien, y me dice que certificados hay cuando ejecuto el ks.aliases(); Muchas gracias por todo, no solo por la ayuda prestada en este caso, sino por toda la librería en sí. Un saludo. |
Por favor leed las descripciones de los commits. Había algún fallo grave (que causaban bloqueos de DNIs).
Muchas gracias por cierto por el pedazo curro de librería :)