OT Autorizace aplikace pomoci klientskeho certifikatu

[Pavel Hudeček]

Viděl bych to takhle:
- Zákazník dostane shrnutí od serveru "Souhrn objednávky" s výpisem počtu 
stránek a dalších údajů, které vedly ke stanovení ceny a za tím cenu.
- Při realizaci objednávky budou údaje ze souhrnu použity jeko limit.

Takže když:
- server dostane data, která mají 1000 barevných stránek A2, ale cena bude 
stanovena pro 100 ČB stránek A6, objednávka se automaticky stornuje.

- server dostane data pro rozeslání 5000 obálek se stránkami A4, ale cena 
bude stanovena pro rozeslání 20 obálek se stránkami A4, vytiskne a pošle se 
20 stránek a další zpraconání se zastaví, zákazník bude vyrozuměn, že data 
obsahovala 4980 stránek navíc oproti závazné objednávce, které nebyly 
rozeslánay.




PH





Od: RV <vicek.radek na cpost.cz>

"Osvetlim o co se jedna...neni to tajne. Pripravujeme novou verzi nasi 
aplikace Podatelna, ktera dokaze vyuzit nove API pro DopisOnline - tedy 
muzete k nam poslat "libovolny" pocet PDF, u kazdeho urcit typ tisku, 
oboustranne/jednostranne, poradi v obalce, data pro slozenku, vybrat 
obalku, zda se adresa vezme textove, nebo vyrezem z prvniho PDF, poradi 
PDF v obalce, postovne, specifikova dorucenku - tohle vse probehne na 
urovni jednoho POST dotazu a odpovedi jsou podaci udaje, nejaky unikatni 
identifikator a samozrejme i okamzite spoctena cena a nebo samozrejme 
nejaky navratovy chybovy kod.

Doted to probiha tak, ze bud nas web nebo klientska aplikace sestavi XML 
(v nem jsou zakodovany i vlastni data do BASE64) a preda je POSTem na 
API bezici na serveru. Ten vytahne XML, rozparsuje ho, vytaha veskere 
PDF a nasledne zacne parsovat tyto PDF zda splnuji pozadovane parametry 
(orientace, zda nesjou sifrovane) a hlavne spocte pocty stranek a listu 
(na zaklade toho zda se u toho PDF pozaduje jedno/oboustrnny text), 
navic jeste provedeme zkusebni vyrezy (prevod do obrazku) adresniho okna 
a provedeme castecnou analyzu zda tam neco je (setrime tim penize 
zakazniku, kteri nejsou schopni napozicovat adresu nebo tam poslou 
kravinu). Je to pomerne brutalni zaprah, kdyz si vezmete, ze se ceka 
odpoved serveru obratem. Je to API takze opravdu multiobratkove rozhrani 
- neni problem, aby od jednoho cloveka prislo 40.000 zasilek za hodinu. 
Vcera jsem ten server otacel a vypada to tam nejak takhle:

Server uptime: 71 days 2 hours 11 minutes 12 seconds
Total accesses: 165622570 - Total Traffic: 11022.5 GB
27 requests/sec - 1.8 MB/second - 69.8 kB/request

tohle je jen otazka trafficu a pristupu (vsechno nejsou jen tyhle 
prenosy - je v tom feedback), ale je treba videt za timhle i ten 
vypocetni vykon na ty operace

Jedine data, kterym lze tedy verit a jsou zavazna, jsou predane XML se 
zakodovanymi PDF.

Vzhledem k tomu, ze pomerne velkou cast objemu generuji uzivatele 
pouzivajici nasi starou aplikaci, ktera byla pomerne tupa a neumi nove 
ficury tak piseme novou. Je velmi lakave presunout vypocetni narocnost 
na PC uzivatelu a provest validace, kontrolni vyrezy a dalsi veci na 
strane uzivatele. A nasledne prenasene XML doplnit o jiz spoctene pocty 
stran - navic odpadne hromada prenosu jiz tim, ze aplikace zjisti 
nejakou chybu rovnou. Problem je to, ze kdyz nam nekdo bude podvrhovat 
chybne pocty stran tak se budou chybne kalkulovat ceny - je na to 
navazano cena za papir, tisk a i vaha zasilky a tedy postovne.

Resime tedy to jak se posychrovat, ze to je spravne a v pripade, ze 
budeme komunikovat s nasi aplikaci tak API na serveru to bude propoustet 
bez kontrol."
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20141218/b313a5e3/attachment.html>