Client interface changes for v3.0 - please comment

todvora commented 7 years ago

There are some flaws and imperfections in this EET client implementation which I'd like to fix in next major release 3.0. Please feel free to add some more or comment on current:

[x] Make all request data available before they are submitted (persistence, logging, failover reasons).
[x] Be able to serialize request to String (persistence, logging)
[x] Convert EET OdpovedType.OdpovedChybaType to proper exception, do not force user to check it manually.
[x] Make repeated submission easier: restore original request from persistence, update fields like TrzbaType.TrzbaHlavickaType.uuidZpravy, TrzbaType.TrzbaHlavickaType.datOdesl or TrzbaType.TrzbaHlavickaType.prvniZaslani
[x] Check and regenerate security codes (BKP, PKP) in second and every other re-submission.
[ ] Make EET warnings OdpovedType.varovani easier accessible and usable.
[ ] Compare BKP from request and response and handle difference if occurs.
[ ] Drop OpenJDK 6 support - EoL December 2016 (leads to cleaner and simpler code).
[x] Should EET root CA for test and production be included in the client? It makes initial configuration much harder for every implementer right now.
[x] Add OCSP to current CRL checking? Not possible, only production cert support OCSP, playground only CRL.
[x] Introduce a demo main class, to be able to execute the jar directly and test communication? Created separate demo project: https://github.com/todvora/eet-client-demo
[x] Remove BouncyCastle dependency (see #27).
[x] Change logging from log4j to slf4j-api (#28)

Changes mentioned here will be implemented on branch client-interface-changes, if you want to review the code, send pull request or check, how is the client evolving.

Dacesilian commented 7 years ago

Generování zprávy trvá relativně dlouho i na výkonném počítači. Je možné to zrychlit?

19:39:04.502 - volání client.submitReceipt 19:39:05.944 - (WebserviceLogging.java:20) - Outbound Message 19:39:06.117 - první (InMemoryCRLStore.java:103) - CRL loaded from URI 19:39:06.269 - poslední CRL loaded from URI 19:39:06.312 - odesláno

Trvá to cca 1810 milisekund. Nejsem si jistý, co tak trvá. Je možné CRL stáhnout předem a specifikovat cestu na disku, aby se nemusely pokaždé stahovat?

FIK dostanu v pořádku, takže je to použitelné, ale 2 sekundy prodleva je nepříjemná.

Děkuji.

todvora commented 7 years ago

Ta prodleva je opravdu kvůli načítání CRL. Ty se ale načítají jen při prvním odeslání a následně jsou cachované v paměti. Stáhnout CRL předem nedává moc smysl, protože se pravidelně aktualizují.

Je klient vytvářen pro každé odeslání zvlášť, nebo zůstává vytvořená instance, která se znovu použije?

Řešením by bylo vynechat CRL a použít jen OCSP, to ale zas vytváří request při každé přijaté odpovědi. I když, pravda, rychlý a s minimální datovou náročností.

Dacesilian commented 7 years ago

Máte naprostou pravdu. Měl jsem to zkusit rovnou několikrát bez restartu :) Opravdu to trvá už jen cca 170 ms. Takže stažení CRL jen poprvé je v pořádku.

todvora commented 7 years ago

Díky za info. V logu si všimněte hlášek:

2017-02-09 19:25:57.188 [pool-4-thread-1] INFO  cz.tomasdvorak.eet.client.security.crl.InMemoryCRLStore - CRL loaded from URI http://qcrldp1.ica.cz/rca15_rsa.crl, storing in cache. Next update: Thu Feb 08 11:45:44 CET 2018

CRL obsahuje informaci, do kdy je platný. Tu následně knihovna využívá, aby včas provedla update CRL a získala seznam nově zneplatněných certifikátů.

todvora / eet-client

Client interface changes for v3.0 - please comment #15